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Preface 


The  purpose  of  this  research  was  to  determine  whether  the 
incorporation  of  Electronic  Data  Interchange  (EDI)  would  irnprove  the 
process  of  coordinating  the  AF  Form  601,  Equipment  Action  Request.  This 
form,  which  is  initiated  by  beise  level  vehicle  managers  and  coordinated 
through  MAJOQMs  and  WR-ALC,  is  used  to  obtain  authorizations  and 
allowances  for  vehicles  and  other  registered  equipment.  The  process  of 
mailing  the  601  to  each  coordinating  agency  is  both  time-consuming  and 
paperwork-intensive.  The  incorporation  of  EDI  would  allow  the 
information  on  the  form  to  be  transmitted  electronically,  saving  time 
and  adding  value  to  the  process  at  all  levels. 

By  defining  the  system  as  it  exists  and  mimicking  that  flow  in  a 
computer  simulation  model,  the  effects  of  EDI  on  the  process  were 
evaluated.  Indications  are  that  the  reduction  in  transmittal  time  alone 
will  result  in  a  modest  decrease  in  cycle  time,  but  that  reductions  in 
processing  times  hold  even  greater  potential  for  process  inprovement. 

Without  the  help  of  numerous  people,  this  research  would  not  have 
been  possible.  I'd  like  to  thank  ir^  advisor,  Lt  Col  Robert  Trenpe, 
whose  enthusiasm  and  insight  provided  me  with  the  motivation  to  go  forth 
with  this  project.  I'd  also  like  to  thank  Mr.  Charles  Myers  and  'j:. 
Sonny  Johnson  at  WR-ALC/LZE,  who  provided  framework  for  developing 
the  model.  Finally,  I'd  like  to  thank  my  wife  Diane  and  my  boys  Andrew 
and  Kyle  for  their  patience  eind  encouragement  throughout  this  process. 

Captain  Charles  T.  Butler 
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Abstract 

This  research  examined  the  effects  of  the  incorporation  of 
Electronic  Data  Interchange  (EDI)  on  the  USAF  vehicle 
allowance/authorization  process.  The  study  utilized  a  ccrnputer 
simulation  model  to  mimic  the  flow  of  the  AF  form  601,  Equipment  Action 
Request,  as  it  is  submitted  at  base  level  and  coordinated  through  the 
MAJOOM  and  WR-ALC.  The  hypothesis  was  that  the  al lowance/ authorization 
cycle  time  could  be  made  shorter  by  transmitting  the  information 
contained  on  the  form  601  electronically,  rather  than  mailing  the  form 
to  each  coordinating  agency. 

In  order  to  compare  the  process  with  and  without  the  use  of  EDI , 
two  ccrnputer  simulation  models  were  developed,  one  which  reproduced  the 
current  system  and  another  whose  variables  and  parameters  were  modified 
to  simulate  the  effects  of  EDI.  The  output  from  the  models  was  ccnpated 
by  using  a  paired- t  test  to  determine  differences  in  average  system 
residence  time  for  the  601, 

The  incorporation  of  EDI  wais  found  to  produce  modest  inprovements 
in  601  residence  times  —  the  time  elapsed  in  the  coordination  process 
between  601  submittal  and  approval .  Mean  residence  times  were  reduced 
by  approximately  nine  days  by  transmitting  the  information 
electronically.  Additionally,  it  was  found  that  reductions  in 
processing  times  hinted  at  even  greater  reductions  in  average  601 
residence  times. 
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A  CCMPUTER  SIMULATION  ANALYSIS  OF 
THE  USAF  VEHICLE 
ALLCWANCE/AUTHC»IZATION  PROCESS 


I .  Introduction 


General  Issue 

Air  Force  Systems  Ccmmand  and  other  MAJCCM  vehicle  nanagers  devote 
an  enormous  amount  of  time  to  the  administration  and  management  of 
vehicle  allowances  and  authorizations.  Because  they  prescribe  the 
number  of  vehicles  that  can  be  acquired  or  on  hand  at  a  given 
organizational  level,  vehicle  allowance  and  authorization  levels  must  be 
carefully  managed  to  ensure  the  best  use  of  limited  vehicle  assets. 

Vehicle  managers  must  also  be  able  to  respond  quickly  to  the 
constantly- changing  missions  of  the  units  they  support.  Changes  in 
weapons  system  types  or  quantities,  new  mission  taskings,  or  changes  in 
unit  organizational  structure  can  all  affect  the  number  of  vehicles 
required  for  successful  mission  support.  The  contribution  that  vehicles 
provide  to  mission  support  can  be  reflected  in  the  investment  that  they 
represent.  The  Air  Force  currently  has  approximately  128,500  vehicles 
in  its  fleet,  with  a  purchase  value  of  almost  $3.2  billion.  Replacing 
each  of  those  vehicles  would  cost  approximately  $4  billion  (Wiggins, 
1991).  Vehicles  are  also  a  critical  wartime  asset.  The  Air  Force 
prepositioned  or  shipped  approximately  9000  vehicles  to  support 
operations  in  the  recent  Gulf  war  (Berle,  1991), 

The  ability  to  jvistify  euid  acquire  vehicles  is  a  key  measure  of 
how  well  the  vehicle  manager  performs  his  or  her  assigned  duties; 
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however,  a  variety  of  factors  combine  to  limit  the  manager's  capability 
to  quickly  authorize,  much  less  eissign,  assets  to  meet  those  needs. 
First,  Congress  has  mandated  ceilings  which  limit  USAF’s  total  inventory 
of  certain  varieties  of  vehicles,  particularly  general  purpose  vehicles. 
Additionally,  limits  have  been  placed  on  the  number  of  new 
authorizations  which  can  be  approved.  Although  vehicle  ^les  of 
Allowances  have  been  tailored  to  meet  the  needs  of  individual  units, 
this  "tight  fit"  of  allowances  to  assets  leaves  little  room  to 
facilitate  increases  in  vehicle  levels  stemming  from  misirion  change 
(Johnson,  1990). 

Other  administrative  requirements  place  constraints  on  vehicle 
manacanent  flexibility,  particularly  the  allowance/authorization 
process.  Current  allowance/ authorization  management  primarily  involves 
tracking  current  vehicle  assignments,  requesting  approval  for  new 
allowances/authorizations,  and  requesting  changes  to  existing  ones. 

These  approval  requests  are  documented  and  routed  on  the  Air  Force  (AF) 
Form  601,  Equipment  Action  Request.  All  actions  regarding  changes  to 
vehicle  allowance/authorization  levels  must  be  submitted  on  the  Form 
601,  which  is  subsequently  routed  from  base  fleet  managers,  through  the 
MAJCOM,  to  AFLC,  and  often  to  Item  Managers,  the  functional  experts 
throughout  AFLC.  This  process  is  time-consuming,  affecting  the  fleet 
manager's  ability  to  make  timely  decisions.  Given  the  need  for  base 
level  flexibility  in  reassigning  and  acquiring  vehicle  assets,  vehicle 
managers  at  HQ/AFSC  have  posed  the  question,  "What  are  the  shortcomings 
in  +'hi  vehicle  allowance/authorization  process  and  how  can  we  manage  it 
better  from  a  user's  perspective?" 
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Problem  Statanent 


The  USAF  vehicle  allowance/authorization  process  contains 
shortcomings  which  inhibit  the  eibility  of  wing  and  major  ccmmand- level 
managers  to  respond  quickly  to  changes  in  vehicle  fleet  requirements. 

Process  Definition 

Before  the  research  can  make  any  eissiarptions  about  the 
allowance/authorization  process,  the  process  must  be  defined  and 
examined  in  its  existing  form.  The  system's  boundaries  —  for  purpc  3S 
of  the  study  at  hand  —  were  determined  to  include  only  the  601  approval 
and  coordination  process  for  vehicle  allowances/authorizations.  The 
process  under  study  does  not  include  other  related  or  offshoot  processes 
such  cis  the  Vehicle  Priority  Buy  or  other  vehicle  acquisition  processes. 

The  process  begins  at  the  point  that  the  601  was  submitted  by  the  base 
level  user  for  consideration  by  the  MAJCXH  and  ends  when  the  unit  has 
been  notified  ti.at  the  req’jest  has  been  either  approved  or  disapproved 
at  one  of  the  various  decision  points  in  the  flow. 

Formal  guidance  for  the  allowance/ authorization  process  can  be 
found  in  AFLC  Regulation  67-14,  Air  Force  Equipment  Allowance  Management 
Program.  This  regulation  provides  instructions  for  proper 
documentation,  coordination,  and  processing  of  AF  Forms  601.  Although 
new  veliicle  allowance/authorization  change  requests  are  generated 
through  nurerous  circumstances,  such  as  support  equipment  acquisition 
for  major  weapons  systems,  the  priirery  process  focus  for  this  research 
is  change  requests  initiated  at  base  or  ccmmand  level  in  response  to 
minor  mission  changes. 
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whenever  baise  vehicle  managers  determine  —  usually  from  user 
input  —  that  a  unit  requires  additional  vehicles  to  accomplish  its 
mission,  two  particular  constraints  prohibit  them  from  arbitrarily 
assigning  vehicles  to  fill  that  perceived  need.  The  first  is  a  Table  of 
Allowances  (TA)  which  prescribes  the  number  of  items  of  a  particular 
category  of  support  equipment  permissible  for  use  by  a  imit.  Allowable 
vehicle  levels  and  types  are  governed  by  TA  012.  Alloweinces  are 
standardized  by  organization,  function,  facility,  or  individual 
specialist  according  to  a  basis  of  issue  (BOI).  BOIs  further  define 
allowable  support  equipment  levels  according  to  the  specific  needs  of  a 
given  organizational  type  and  level.  Allowances  are  managed  by  AFLC  via 
the  USAF  Equipment  Management  System  (AFEMS)  (HQ  AFLC,  1984;5). 

Another  constraining  factor  governing  permissible  vehicle 
quantities  is  authorizations.  Authorizations  are  conmand-defined  levels 
governing  the  number  of  vehicles  permitted  in  individual  units.  These 
levels  are  generally  more  restrictive  than  those  prescribed  by  the  TA. 
Cormands  list  authorized  vehicle  levels  by  type  in  a  vehicle 
authorization  list  (VAL).  The  TA  is  the  overriding  document  —  a 
vehicle  can  be  allowed  and  not  authorized  but  not  vice  versa.  Before  a 
vehicle  can  be  physically  sissigned,  it  must  be  both  allowed  and 
authorized  (HQ  USAF,  1987;36). 

Changes  to  the  TA  eUid  VAL  are  requested  via  the  AF  Form  601, 
Equipment  Action  Request.  When  vehicle  managers  wish  to  increase  the 
number  of  vehicles  aissigned  to  a  particular  unit,  they  must  first 
consult  TA  012  to  ensure  that  the  vehicle  is  allowed.  Mditionally, 
they  must  consult  the  carmand  VAL  to  determine  the  number  and  types  of 
vehicles  that  may  be  assigned  for  that  function.  If  both  allowances  and 
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authorizations  do  not  exist  for  that  function,  the  base  Vehicle 
Operations  Branch  initiates  action  to  obtain  them  (HQ  AFLC,  1989;5). 

The  first  step  in  the  process  is  to  obtain  approval  of  the  Vehicle 
Authorization  and  Utilization  Board  (VAUB).  This  board,  chaired  by  the 
base  Deputy  Ccnmander  for  Resources,  and  consisting  of  personnel  from 
key  functional  areas,  validates  the  requirement  against  mission  needs, 
alternative  transportation  sources,  and  other  factors.  If  the  request 
is  approved  by  the  VAUB,  the  Vehicle  Operations  Officer  (VOO)  prepares 
the  Form  601.  The  601  contains  justification  to  include  expected 
vehicle  utilization,  effect  on  mission  requirements,  number  of  vehicles 
currently  authorized  and  assigned,  and  other  data  directed  at 
determining  mission  criticality.  The  form  is  signed  by  the  base  Chief 
of  Transportation  and  forwarded  to  the  Registered  Equipment  Management 
System  (REMS),  a  supply  automated  system  for  tracking  equipment 
allocations.  The  REMS  manager  logs  the  date  that  the  request  was 
forwarded  to  higher  headquarters  and  sets  a  suspense  for  follow  up  (HQ 
AFLC,  1989; 5) 

Once  the  request  has  been  approved  by  all  base  agencies,  it  is 
forwarded  to  the  MAJCOM  for  further  review.  The  MAJOQM  Command 
Equiprnent  Management  Office  (CEMO)  evaluates  the  request  against  current 
authorization  and  allowance  levels  and  against  mission  requirements. 
Evaluations  are  carefully  screened  since  authorization  ceilings  for  some 
vehicle  types  may  require  that  a  lower-priority  authorization  is  deleted 
for  every  new  one  approved  (HQ  AFLC,  1989;5). 

Requests  that  require  allowance  changes  or  additions  are  forwarded 
to  WR-ALC/LZE  for  TA  manager  approval .  Because  many  corrmands  have 
closely-aligned  allowance  and  authorization  levels,  simple  vehicle 
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rotations  or  recissignments  may  generate  this  type  of  action.  In 
addition  to  ensuring  that  the  request  contains  all  of  the  appropriate 
data,  the  TA  manager  reviews  each  request  carefully  against  the  same 
mission  criteria  that  was  reviewed  at  lower  echelons.  Additionally,  the 
TA  manager  may  coordinate  with  the  responsible  AFLC  Item  Manager  (IM)  to 
further  validate  the  requirement.  This  IM  may  be  located  at  another 
base,  adding  days  to  the  coordination  process.  Some  of  the  Item 
Manager's  duties  in  this  regard  are  to  determine  whether  suitable 
vehicles  exist  in  the  present  inventory,  or  whether  a  completely  new 
vehicle  type  is  required.  If  a  new  vehicle  type  is  required,  the  IM 
conducts  further  coordination  with  the  USAF  Cataloging  and 
Standardization  Center  (CASC)  at  Battle  Creek,  Michigan.  CASC  assigns 
stock  numbers  to  these  new  requirements  (Johnson,  1990). 

The  TA  rronager  has  15  calendar  days  in  which  to  process  601s.  In 
the  event  that  coordination  reqmrements  are  anticipated  to  exceed  15 
days,  the  CEMO  is  notified.  If  written  coordination  is  required  from 
another  staff  agency,  the  TA  manager  is  granted  an  additional  15  days  to 
process  the  request.  The  CEMO  will  be  advised  of  approved  requests 
granting  interim  authority  to  change  FIEMS  data  to  reflect  the  new 
allowance/authorization.  This  will  permit  managers  to  irrmediately  take 
action  to  fill  a  requirement  (HQ  AFLC,  1984;20-21) . 

Current  Efforts  to  Automate  the  601  Process 

Air  Force  Vehicle  managers  have  not  overlooked  the  possibility  of 
automating  the  601  process.  In  fact,  efforts  are  currently  underway  to 
develop  an  EDI -integrated  program  for  equipment  management  Air  Force¬ 
wide.  EX'I ,  or  Electronic  Data  Interchange,  is  described  by  Eirmeihainz 


1-6 


as  "the  interorganizational  exchange  of  business  documentation  in 
structured,  machine-processable  form."  The  Air  Force  Equipment 
Management  System  (AFEMS),  currently  under  development  by  the  Martin- 
Marietta  Corporation,  will  provide  vehicle  managers  with  an  on-line 
capability  to  exchange  the  information  currently  captured  by  the  601  in 
just  that  sort  of  format.  Accessed  from  personal  computers  at  base 
level,  the  system  will  connect  users  at  all  levels  with  a  mainframe- 
driven  database  at  HQ  AFLC.  AFEMS  is  scheduled  for  completion  in 
September  1993,  with  a  final  operating  capability  cost  of  $78  million 
(Harding,  1991). 

AFEMS  will  offer  several  featuures  which,  once  implemented,  will 
revolutionize  the  way  Air  Force  (AF)  equipment,  including  vehicles,  are 
managed.  Because  the  mainframe  will  serve  as  a  host  for  information 
flowing  among  a  network  of  users,  information  transfer  will  be  virtually 
instantaneous.  Once  a  user  has  executed  one  of  the  various  functions 
(including  601  processing)  available  through  the  system,  user-designated 
coordination  authorities  at  each  level  will  also  have  iirmediate  access 
to  that  information  (Harding,  1991). 

Ajiother  significant  feature  of  AFEMS  is  the  ability  to  "build"  a 
601  by  accessing  a  set  of  screen  terplates  designed  for  that  purpose. 

Not  only  does  each  of  the  nine  terplates  have  preformatted  fields  in 
which  to  type  the  necessary  codes,  figures,  etc.,  but  the  database  also 
contains  the  current  inforrration  necessary  to  complete  the  template 
automatically.  For  instaince,  if  a  base  vehicle  manager  wishes  to  submit 
a  601  req’jesting  a  new  forklift,  he  or  she  may  only  need  to  complete  a 
very  cursory  series  of  preparatory  blocks  such  as  organization,  vehicle 
type,  etc.  The  database  contains  equipment  data  pertaining  to  that  unit 
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including  the  number  currently  allowed,  authorized,  and  assigned  — 
and  can  extrapolate  the  remaining  supply  information  necessary  to 
"build"  the  request  (Harding,  1991). 

This  ability  to  access  all  codes  necessary  to  ccnplete  the  request 
should  be  faster  and  more  accurate  than  the  current  method,  which  can 
require  research  into  several  paper  documents  to  obtain  the  proper 
information  necessary  for  coordination.  Once  the  appropriate  blocks 
have  been  filled  in,  the  request  can  be  saved  to  the  database,  where  it 
can  be  instantly  accessed  by  coordination  agencies  at  each  level 
(Harding,  1991). 

The  system  can  also  prorrpt  the  user  when  mistakes  occur.  For 
example,  if  an  uncataloged  national  stock  number  or  allowance 
identification  code  is  entered,  the  system  will  inform  the  user. 
Additionally,  the  screen  data  fields  will  prohibit  users  from  entering 
too  many  characters  for  a  particular  code  (Harding,  1991). 

Although  this  research  does  not  attempt  to  evaluate  or  validate 
AF5MS,  seme  of  the  features  of  AFEMS  will  be  used  in  experimental  morels 
to  validate  or  fail  to  validate  the  use  of  EDI  as  a  means  of  improving 
the  601  process.  For  example,  later  models  will  incorporate  the  concept 
or  instantaneous  information  transmittal  as  an  assumption  for 
experimentation . 

Investigative  Questions 

Before  mvaking  any  firm  conclusions  about  process  improvements,  the 
research  must  ultimately  answer  the  question,  "How  can  the 
a: iowance/authorization  process  be  improved  from  the  users' 
perspective?"  Investigation  will  begin  with  an  in-depth  analysis  of  the 
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system  as  it  exists.  "What  are  the  current  process  flows?"  "What  are 
the  major  constraints  within  the  process?"  "Who  owns  the  process?"  "Who 
are  the  customers  or  beneficiaries  of  the  process?"  Once  the  process 
has  been  defined,  research  can  concentrate  on  the  mechanics  of  the 
process.  Several  questions  must  be  answered,  including,  "To  what  extent 
do  decisions  affect  the  performance  of  the  process?"  "What  factors 
contribute  to  process  flow  rate?"  To  answer  these  questions  the 
research  should  contain  some  method  of  making  these  process  flows 
visible  and  measurable.  Probably  the  best  way  to  achieve  this  degree  of 
meausurability  is  by  using  computer  simulation  to  model  the  system  and 
adjusting  the  inputs  to  refleot  the  dynamics  of  the  process.  Simulation 
should  reveal  the  shortcomings  in  the  process  and  provide  some  insights 
into  ways  that  the  process  can  be  improved. 

Guiding  Hypothesis 

The  guiding  hypothesis  that  has  emerged  from  initial  analysis  of 
the  system  is  that  the  integration  of  electronic  data  interchange  into 
the  601  process  will  improve  overall  process  performance  and  overcome 
the  effects  cf  varying  input  parameters.  5y  transmitting  the 
information  contained  in  the  form  601  electronically,  rather  than 
mailing  the  form  between  the  various  decision  points,  the  overall 
processing  time  of  the  601  will  be  reduced. 

Methodology  Overview 

This  research  will  utilise  computer  simulation  to  model  the 
present  allowance/authorization  process  as  it  is  prescribed  by 
regulation,  and  as  it  is  perceived  by  the  users  and  agencies  who  have 
inputs  to  the  process.  The  scope  of  the  process  to  be  studied 
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enccmpasses  the  flow  of  the  AF  Form  601,  the  primary  document  used  to 
request  approval  for  or  changes  to  vehicle  allowances  and 
authorizations.  Once  each  process  step  has  been  identified  and  modeled 
in  its  various  forms,  the  model  will  be  modified  to  incorporate 
hypothesized  ii^provements  so  that  their  effects  can  be  tested.  The  601 
is  the  entity  which  will  provide  visibility  of  system  performance.  The 
primary  measure  of  merit  will  be  the  601  residence  time,  or  the  amount 
of  time  between  601  submittal  at  base  level  and  approval  at  WR-ALC. 

Sunmarv 

Thus  far,  initial  research  has  concluded  that  the  AF  form  601 
process  is  a  critical  element  in  vehicle  managers'  ability  to  respond 
quickly  to  mission  changes  which  affect  vehicle  requirements.  The 
application  of  EDI  holds  seme  interesting  potential  for  reducing  the 
time  necessary  to  coordinate  allowance/authorization  approval,  thus 
innproving  the  value  of  the  process  to  managers  at  all  levels.  Before 
making  conclusions  about  the  degree  of  inprovement  which  might  be 
obtained  through  EDI,  subsequent  research  must  establish  the  basis  for 
using  EDI,  as  well  as  methods  for  assessing  the  effects  of  EDI.  Chapter 
II,  Literature  Review,  will  further  examine  EDI  as  a  method  of  inproving 
processes,  and  will  also  look  at  conputer  simulation  modeling  as  a 
method  of  evaluating  processes. 
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II .  Literature  Search 


Introduction 

Before  exarnining  the  specific  methodology  that  the  research  will 
take,  it  is  inportant  to  look  at  EDI  as  a  concept,  and  to  review  some  of 
the  literature  concerning  systems  and  modeling.  This  review  will 
provide  some  basis  for  the  structure  that  later  experimentation  will 
taike.  First,  the  review  will  define  the  concept  of  EDI,  as  well  as  some 
of  EDI's  advantages  and  current  applications.  The  review  will  also 
discuss  the  characteristics  of  systems  such  as  the  601  process,  and  will 
look  at  simulation  imdeling  as  a  method  of  capturing  the  flows  inherent 
in  systems.  This  review  will  lay  the  groundwork  for  the  experimentation 
methodology,  which  will  be  discussed  in  Chapter  III. 

Options  for  Process  Improvement 

The  601  process  involves  an  exchange  of  information  between 
agencies  at  widely-separated  locations.  The  distribution  of  this 
information  —  both  between  points  on  the  same  base  and  between  bases  — 
adds  days  to  the  601  coordination  process.  The  physical  movement  of  the 
601  form  complicates  decisionmaking  and  slows  the  process  of  meeting 
urgent  mission  requirements. 

Reducing  the  amount  of  time  necessary  to  process  601s  could  take 
several  forms.  First,  the  number  of  601s  submitted  could  be  reduced, 
decreasing  the  workload  on  the  managers  who  must  process  them.  The 
amount  of  time  necessary  to  process  the  information  at  each  level  could 
likewise  be  reduced.  The  nuiiber  of  processing  activities  could  be 
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decreased,  speeding  the  flow  of  information  through  the  system. 

Finally,  the  amount  of  time  the  information  spends  between  processing 
points  could  be  reduced. 

Because  AF  vehicles  represent  an  expensive  and  mission-critical 
group  of  equipment  items,  individual  accountability  is  a  must.  The  601 
helps  to  provide  that  accountability;  therefore,  reducing  the  nvmber  of 
601s  suhnnitted  to  document  management  actions  does  not  appear  to  be  a 
viable  option,  at  least  in  the  near  term.  Similarly,  ccrmand  and 
logistics  support  coordination  is  necessary  to  ensure  that  vehicles  are 
effectively  allocated  and  assigned.  Reduction  in  the  nunrtber  of 
processing  points  could  negatively  impact  mission  validation  when 
considering  the  needs  of  requesting  units.  Finally,  a  reduction  in 
processing  time  at  each  management  level  would  require  streamlining  a 
carpi  ex  supply  accountability  system  that  manages  not  only  vehicles,  but 
also  registered  equipment  of  all  types. 

EDI  —  A  Possible  Solution 

The  remaining  option,  shortening  the  intransit  time  between 
information  processing  points,  is  technologically  feasible  through  the 
application  of  Electronic  Data  Interchange  (EDI).  Defined  by  Elrmelhainz 
ais  "the  interorganizational  exchange  of  business  docimentation  in 
structured,  machine-processable  form,"  EDI  has  beccme  aui  accepted  method 
of  transmitting  business  information  for  many  applications.  More  than 
simply  replacing  paper  documents  with  electronic  documents,  EDI  is 
actually  a  way  of  replacing  manual  data  with  electronic  data. 

Ehmelhainz  further  points  out  that  "the  purpose  of  EDI  is  not  to 
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eliminate  paper,  but  rather  to  eliminate  processing  delays  and  manual 
reentry"  (Eitmelhainz,  1990; 4). 

Traditional  forms  of  information  flow  contains  at  least  four 
inherent  disadvantages.  First,  paper-beised  systems  increase  the  time 
reqiiired  to  process  information.  One  of  the  primary  sources  of  delays 
is  the  time  it  tadces  to  physically  transfer  the  information  between 
processors,  whether  handcarried,  telephoned,  or  in  the  case  of  the  601, 
mailed.  Paper-based  systems  also  suffer  from  low  accuracy,  particularly 
systems  which  require  a  large  amomt  of  data  entry.  This  disadvantage 
becomes  further  evident  when  that  data  must  be  rekeyed  at  multiple 
processing  points.  Manual  reentry  produces  another  undesirable  side 
effect  of  paper-based  systems,  that  of  increased  labor  usage. 

Corparison  of  the  manual  entry  with  soxarce  documents  further  adds  to  the 
burden  of  ensuring  the  accuracy  of  each  process.  Finally,  increased 
uncertainty  results  from  variations  in  mail  and  distribution  systems 
used  to  transmit  information  (Ehmelhainz,  1990 ; 4, 9-10 ) . 

The  601  process  suffers  from  each  of  these  problems.  Transmittal 
is  by  mail,  increasing  intransit  time  and  uncertainty.  The  numerous 
codes  and  figures  which  must  be  entered  on  the  601  present  numerous 
opportunities  for  mistakes  at  the  source,  and  create  additional 
reconciliation  burdens  downstream.  Finally,  additional  ccrmuni cation  is 
required  to  acknowledge  receipt  at  each  level  and  to  coordinate 
correction  of  form  discrepancies. 

Replacing  these  paper-based  systems  with  an  electronic  information 
flow  offers  possible  solutions  to  these  problems.  Among  the  advantages 
cited  by  Elrmelhainz  are  improved  operations,  increased  customer 
responsiveness,  improved  channel  management,  and  increaised  ability  to 
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ccrpete  internationally  (Ehmelhainz,  1990;25).  The  first  two  of  these 
benefits,  and  to  a  lesser  degree  the  third  and  fourth,  are  worthy  goals 
for  the  601  process  eis  well  as  other  internal  and  external  DoD 
operations. 

Usually  EDI  is  implemented  as  a  means  of  streamlining 
ccmnuni cat ions  with  external  organizations;  however,  EDI  can  benefit 
internal  operations  within  organizations  as  well.  One  by-product  of  the 
EDI -implementation  process  is  a  complete  assessment  of  current 
operations.  Before  EDI  Cein  flow,  current  paperwork  flows  must  be 
analyzed,  and  many  organizations  find  that  this  analysis  spots 
weaknesses  in  processes  and  policies.  Thus,  the  EDI  inplementation 
process  forces  organizations  to  determine  what  the  perceived  and  actual 
flows  are  and  make  corrections  to  them  if  needed  (Bnrmelhainz,  1990 ; 33- 

34) . 

EDI  may  improve  internal  stability  by  decreasing  processing  times 
and  increaising  the  certainty  associated  with  those  processes.  For 
instcince,  Eiimelhainz  describes  how  the  Ford  Motor  Carpany  has  integrated 
its  EDI  system  with  its  Just-In-Time  (JIT)  production  system.  The  JIT 
system  depends  on  the  timely  delivery  of  parts  to  maintain  critical 
production  schedules.  Because  EDI  has  been  integrated  into  the 
purcheising  process,  the  purchasing  timeline  has  been  reduced  and 
production  schedules  experienced  more  stability  (Eirmelhainz ,  1990;34- 

35) ,  Vehicle  managers  at  all  levels  would  be  the  beneficiaries  of  this 
improved  responsiveness  if  EDI  proved  as  effective  for  the  601  process. 

Another  way  in  which  EDI  improves  internal  operations  is  through 
improved  personnel  productivity.  EDI  eliirdnates  much  of  the 
administrative  activity  associated  with  preparing  documents,  thus 
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freeing  personnel  for  other  duties.  George  Klima,  former  Director  of 
Accounting  Systems  for  Super  Valu  stores  notes  that  buyers  in  that 
organization  once  viewed  their  roles  as  priirarily  administrative. 
Following  the  irrplementation  of  EDI,  however,  they  view  themselves  as 
merchandisers.  Because  EDI  eliminates  many  of  the  nuisance  tcisks 
eissociated  with  lost  or  incorrect  orders,  salespeople  and  buyers  sense 
an  increased  measure  of  professionalism  in  their  jobs  (Enrmelhainz, 
1990;35-36).  Boland  echoes  this  finding,  noting  that  without  EDI, 
salespeople  spend  as  much  as  50  percent  of  their  time  on  paperwork 
(Boland,  1989;140).  Because  the  601  process  is  primarily  an 
administrative  function  that  stems  from  other  vehicle  management 
activities,  benefits  resulting  from  EDI  could  have  similar  positive 
consequences  for  Air  Force  vehicle  managers. 

Perhaps  the  most  important  benefit  of  EDI  in  terms  of  its  possible 
adaptation  to  the  601  process  is  that  of  inproved  customer  service.  By 
virtue  of  its  ability  to  provide  real-time  status  on  information  in  the 
process  pipeline,  EDI  adds  value  to  managers  who  must  respond  quickly  to 
such  requests,  as  well  as  customers  who  need  status  information  quickly 
(Ehmelhainz,  1990; 36-37).  EDI's  shorter  process  times  could  also  reduce 
the  residence  time  of  601s  in  the  system  —  the  time  spent  between  601 
submittal  and  final  approval  —  thereby  improving  the  process' 
responsiveness  to  vehicle  managers  awaiting  the  outcome  of  request 
coordination. 

Although  the  primary  impetus  for  EDI  in  business  hats  been 
increased  competitiveness,  the  cost  savings  of  EDI  have  not  gone 
unnoticed.  For  example,  the  use  of  EDI  in  the  automotive  indiistry  is 
widely  credited  with  saving  $200  per  vehicle.  These  savings  come  from 
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several  sources  including  reductions  in  document  processing  costs, 
reductions  in  personnel  levels,  reductions  in  inventory,  and  reductions 
in  freight  and  handling  charges  (Eiimelhainz,  1990;28-31).  The  National 
Association  of  Purchasing  Management  estimates  that  EDI  can  cut  the 
bottom-line  cost  of  transactions  by  20  to  60  percent.  Tliese  reductions 
come  from  an  estimated  50  percent  reduction  in  work  hours  in  the 
purchasing  cycle  (Boland,  1989;142)  Reductions  in  document  processing 
costs  and  personnel  levels  appear  to  hold  the  most  potential  for  the  601 
process . 

Document  processing  cost  savings  vary  from  industry  to  industry; 
however,  savings  are  tied  to  the  costs  of  processing  the  document  prior 
to  the  iirplementation  of  EDI.  One  study  of  U.S.  managers  revealed  that 
EDI  offers  a  10-to-l  cost  benefit  in  the  processing  of  purchase  orders. 
The  study  showed  that  a  paper  document  that  is  typed,  revised,  and 
mailed  costs  upwards  of  $4:,  while  a  similar  document  that  is  prepared 
and  transmitted  electronically  costs  just  $5.  Hewlett-Packard  claims  a 
decrease  of  from  $1.65  to  $0.58  per  purchase  order.  The  Automotive 
Industry  Action  Group  has  noted  a  savings  of  $12  per  document  through 
the  use  of  EDI  (Ehmelhainz,  1990; 28-29). 

Current  EDI  Applications 

EDI  is  currently  in  use  —  and  is  showing  tremendous  growth  — 
across  a  diverse  range  of  industries.  Ehmelhainz  notes  that  a  1988 
survey  showed  that  over  34  percent  of  Fortune  1000  conpanies,  large 
universities,  and  government  agencies  were  using  EDI.  Another  20 
percent  were  in  the  process  of  planning  or  inplementing  EDI  (Ehmelhainz , 
1990; 41) . 
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The  transportation  industry  and  government  have  both  seen 
tremendo’us  grovrth  in  the  use  of  EDI.  The  transportation  industry  vras 
among  the  first  to  develop  EDI  on  an  industry-wide  basis,  and  in  fact 
pioneered  much  of  the  architecture  and  standards  used  in  EDI  today.  The 
rail  industry  is  among  the  most  advanced  EDI  users,  applying  the 
technology  to  iranage  waybills,  locate  railcars,  and  transmit  purchase 
orders  and  freight  bills.  Shipper  agent  Interamerican  Transport  Systems 
has  used  EDI  to  shave  16  man-hours  per  day  off  of  the  time  required  to 
track  rail  cars  manually.  Conrciil  has  experienced  similar  success  in 
managing  waybills,  reducing  the  time  required  to  tiransmit  waybill 
information  by  facsimile  from  two  hours  to  just  one  minute  through  the 
use  of  EDI  (Einmelhainz ,  1990 ; 42-43) . 

The  trucking  industry  is  also  heavily  engaged  in  EDI,  and  many 
shippers  now  expect  carriers  to  have  EDI  capability.  The  primary  focus 
of  EDI  in  trucking  is  the  electronic  transfer  of  freight  bills.  Yellow 
Freight  Systems,  Inc.  uses  electronic  billing  to  audit,  transfer,  and 
execute  billing  of  its  customers. 

This  technology  has  become  a  part  of  a  larger  effort  to  nurture 
long-term,  stable  customer  relationships.  Procter  and  Gamble  uses  EDI 
primarily  to  manage  its  outbound  freight  bills  in  a  manner  which  reduces 
administrative  requirements  and  allows  customer  service  representatives 
to  spend  more  time  performing  customer  service  tasks  (Ehmelhainz,  1990; 
44-45).  The  U.S.  government  has  also  became  fertile  ground  for  the 
growth  of  EDI.  In  addition  to  the  DoD.  the  Federal  Supply  Service  and 
the  General  Services  Administration  have  begun  using  EDI.  Major  areas 
that  have  embraced  the  use  of  EDI  are  procurement,  retailing,  and 
transportation  (Eirmelhainz ,  1990;57). 
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Eiimelhainz  quotes  David  F.  Baker  of  the  Office  of  Management  and 
Budget  ais  saying,  "If  there  is  any  process  in  the  government  that  is 
made  for  EDI,  and  cries  out  for  EDI,  it  is  procurement."  Indeed,  DoD 
recently  announced  that  it  was  beginning  an  EDI  program  that  would 
require  vendors  supplying  goods  to  the  DoD  to  have  EDI  capability.  7^ 
example  of  this  effort  is  the  Defense  General  Supply  Center's  Paperless 
Ordering  Purchasing  System  (POPS),  which  uses  EDI  to  place  orders  with 
DuPont  and  other  vendors  (Ehmelhainz,  1990;58). 

Government  resale  activities  such  as  the  Army  and  Air  Force 
Exchange  Service  (AAFES)  have  also  benefitted  from  the  user  of  EDI. 

AAFES  is  currently  using  EDI  to  transmit  purchaise  orders  to  14  vendors. 
The  Marine  Corps  is  testing  EDI  at  its  East  Coast  Ccrrmissary  Cctrplex  and 
processes  cibout  40  percent  of  its  orders  electronically.  Military 
retail  purchasers  have  experienced  some  of  the  same  benefits  as 
corrmercial  retailers,  including  reduced  order  processing  time,  reduced 
inventory,  and  increaised  sales  (Onnelhainz,  1990;  59). 

Government  transportation  activities,  like  their  ccmmercial 
counterparts  have  increased  their  use  of  EDI  as  a  way  of  streamlining 
activities.  As  the  world's  largest  shipper,  EDI  offers  the  DoD  many 
potential  applications.  One  target  for  adaptation  to  electronic 
transfer  is  government  bills  of  lading.  In  a  recent  test  of  twelve  DoD 
activities,  three  motor  carriers,  and  three  finance  offices,  EDI  was 
found  to  reduce  both  costs  and  paperwork  associated  with  bills  of  lading 
(Ehmelhainz,  1990;59-60). 

Undoubtedly,  EDI  has  proven  to  be  an  effective  means  of 
streamlining  systems,  improving  responsiveness ,  and  reducing  costs.  As 
Boland  notes,  EDI  can  also  provide  an  opportunity  for  a  ccrrpany  to 
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reevaluate  its  internal  system  flow  and  identify  new  ways  to  coordinate 
information  (Boland,  1989;142).  The  identification  of  those  flows, 
processes,  and  activities  inherent  in  an  organization's  system  — 
whether  for  EDI  implementation  or  other  improvement  goals  —  requires  a 
systematic  approach. 

Systems  Design 

Once  the  system  has  been  mapped  in  its  present  form,  research  into 
its  behavior  must  take  a  structured  approach.  Forrester  hais  outlined  a 
systematic  approach  to  designing  industrial  and  economic  systems; 
however,  his  philosophies  provide  the  framework  for  the  design  of 
smaller  experimental  projects  as  well.  His  study  of  industrial  dynamics 
—  the  study  of  information  feedback  characteristics  of  industrial 
activity  —  captures  many  of  the  attributes  of  the  601  process.  These 
studies  attempt  to  explain  how  organizational  structure,  policy 
amplification,  and  timve  delays  in  decisions  and  actions  interact  to 
influence  the  success  of  the  organization  or  system.  His  theories  also 
treat  the  interactions  between  information  flows,  such  as  those 
represented  in  the  601  process  (Forrester,  1961;1-13),  Forrester's 
industrial  dynamics  approach  to  systems  design  progresses  through 
several  steps : 

1.  Identify  a  problem. 

2.  Isolate  the  factors  that  appear  to  interact  to  create  the  observed 
symptoms . 

3.  Trace  the  cause-and-effect  information  feedback  loops  that  link 
decisions  to  action  to  resulting  information  and  to  new  decisions. 
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4.  Formulate  acceptable  formal  decision  policies  that  describe  how 
decisions  result  from  the  available  information  streams. 

5.  Construct  a  mathematical  model  of  the  decision  policies, 
information  sources,  and  interactions  of  the  system  ccrrponents. 

6.  Generate  the  behavior  through  time  of  the  system  zis  described  by 
the  model . 

7.  Conpare  results  against  all  pertinent  available  knowledge  about 
the  actual  system. 

8.  Revise  the  model  until  it  is  acceptable  as  a  representation  of  the 
actual  system. 

9.  Redesign,  within  the  model,  the  organizational  relationships  and 
policies  which  can  be  altered  in  the  actual  system  to  find  the  changes 
which  improve  system  behavior. 

10.  Alter  the  real  system  in  the  directions  that  model 
experimentation  has  shown  will  lead  to  improved  performance. 

This  outline  forms  an  effective  framework  for  analysis  cf  and 
experimentation  with  the  601  process  (Forrester,  1961;13). 

System  Characteristics 

As  a  carpi  ex  system,  the  allocaticai/ authorization  process  shares 
many  of  the  same  characteristics  as  other  processes;  that  is,  it  is  a 
group  of  interacting  activities  that  form  a  system.  As  such,  the 
process  should  be  viewed  from  a  systems  perspective,  recognizing  that 
optimizing  the  performance  of  the  various  subsystems  may  not  guarantee 
the  optimization  of  the  whole.  Shannon  notes  that  carpi  ex  systems  share 
characteristics  that  beccme  obstacles  to  improving  overall  system 
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performance.  These  are  attributes  that  must  be  considered  vd-thin 
Forrester's  industrial  design  framework  and  include: 

1.  Change.  Systems  rarely  remain  static  for  long  periods  of  time. 
Elements  (entities)  constantly  enter  and  leave  the  system  over  time  in  a 
bi rth-and-death  process.  In  the  vehicle  allowance/ authorization 
process,  AF  Form  601s  are  the  entities  of  interest. 

2.  Environment.  The  environment  contains  all  the  external  variables 
that  can  affect  the  system's  state.  Additionally,  each  system  has  its 
own  subsystems  and  is  often  a  part  of  a  larger  system.  The 
allowance/ authorization  process  is  no  exception.  It  forms  a  subsystem 
of  the  larger  vehicle  acquisition/allocation  process,  and  has  subsystems 
of  its  own,  such  ais  the  flow  loop  for  assigning  National  Stock  Numbers 
(NSN)  to  identify  new  vehicle  types. 

3.  Counterintuitive  Behavior.  Systems  often  display  behavior  which 
is  counter  to  that  revealed  by  casual  observation.  Cause  and  effect 
relationships  may  not  be  readily  apparent  through  time  and  space.  By 
modeling  the  601  flow,  some  of  these  ancmalies  may  become  evident  in  the 
allowance/authorization  process. 

4.  Drift  to  Low  Performance.  Complex  systems  gradually  deteriorate 
towards  a  condition  of  decreased  performance  over  time.  Remedies  for 
this  deterioration  often  do  not  consider  the  counterintuitive  nature  of 
the  system,  and  are  therefore  ineffective  or  further  detrimental  to 
system  performance. 

5.  Interdependency.  Each  event  in  a  system  is  influenced  by  previous 
events  and  will  affect  subsequent  events.  The  effect  of  system  input 
rates  and  flows  is  of  particular  interest  in  this  study.  The  rate  and 
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flow  of  601  inputs  —  and  the  rate  at  which  they  are  processed  —  will 
affect  the  performance  of  each  sequential  activity  in  the  system. 

6.  Organization.  Almost  all  ccrrplex  systems  have  a  hierarchy  of 
parts  and  subsystems  which  interact  to  execute  the  functions  of  that 
system.  In  the  601  process,  cormand  euad  functional  hierarchies  exist 
which  must  interact  effectively  to  manage  authorization/allocation 
approval  (Shannon,  1975;  36-37)). 

System  Modeling 

Given  that  the  601  process  entails  each  of  these  characteristics 
of  systems,  any  in-depth  examination  of  the  process  must  contain  some 
means  of  explaining  the  behavior  of  this  system.  Several  approaches  are 
available  to  give  some  insight  into  the  behavior  of  complex  systems. 

One  is  direct  experimentation.  Direct  experimentation  involves 
interaction  with  the  actual  system  in  order  to  determine  the  effects  of 
various  inputs.  This  method  has  several  disadvantages.  First,  it  is 
extremely  expensive  in  terms  of  manpower  and  resources.  Second,  the 
time  required  to  observe  the  effects  of  these  various  inputs  may  be 
prohibitive.  Direct  experimentation  may  also  preclude  the  necessary 
number  of  e.xperiment  replications  needed  to  statistically  validate  the 
results  of  the  experiment.  Another  approach  for  studying  the  effects  of 
inputs  on  complex  systems  is  ireithematical  modeling.  This  method  also 
has  drawbacks.  For  instance,  most  rrathemetical  models  cannot  capture 
dynamic  or  transient  events.  Mathematical  models  are  also  limited  in 
the  types  of  distributions  that  they  can  sample  from.  Additionally, 
many  systems  are  too  ccrrplex  to  be  effectively  modeled  mathematically 
(Pidd,  1984;8-9). 
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Corrputer  simulation,  then,  must  be  regarded  as  the  best 
alternative  for  capturing  the  behavior  of  a  relatively  corrplex  system 
such  as  the  601  process.  Although  simulation  models  may  require  time 
eind  money  to  construct  and  run,  these  considerations  are  less  iirportant 
when  compared  against  the  cost  of  direct  experimentation  on  the  existing 
system.  Simulations  have  the  capability  of  duplicating  months  or  even 
years  of  real  syabem  operation.  Computer  simulations  can  also  be 
replicated  numerous  times  in  order  to  gain  the  necessary  statistical 
significance  to  draw  inferences  about  system  behavior  (Pidd,  1984, *8-9). 

What  makes  a  good  simulation  model?  Shannon  notes  seven  qualities 
of  good  models: 

1.  It  must  be  simple  for  the  user  to  understand. 

2.  It  must  be  goal  or  purpose  directed. 

3.  It  must  be  robust,  in  that  it  does  not  give  extreme  answers. 

4.  It  must  be  easy  for  the  user  to  control  and  manipulate,  i.e.  it 
should  be  easy  to  communicate  with. 

5.  It  should  be  complete  on  important  issues. 

6.  It  should  be  adaptable,  with  an  easy  procedure  for  model 
modification  or  updating. 

7.  It  should  be  evolutionary,  in  that  it  should  start  simply  and 
become  more  complex,  in  conjunction  with  the  user.  These  steps 
emphasize  the  care  that  must  go  into  developing  an  effective  ccmputer 
sirmul  at  ion  model  (10,22). 

In  order  to  meet  these  criteria,  the  modeler  must  follow  a 
structured  approach  in  developing  a  model  that  will  be  used  to  simulate 
a  real  system.  Shannon  distinguishes  eleven  stages  of  model 
development.  They  include: 
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1.  System  Definition.  Determining  the  boundaries,  restrictions,  and 
measure  of  effectiveness  to  be  used  in  defining  the  system  to  be 
studied. 

2.  Model  Formulation.  Reduction  or  abstraction  of  the  real  system  to 
a  logic  flow  diagram. 

3.  Data  Preparation.  Identification  of  the  data  needed  by  the  model, 
and  their  reduction  to  an  appropriate  form. 

4.  Model  Description.  Description  of  the  model  in  a  language 
acceptable  to  the  computer  to  be  used. 

5.  Validation.  Increasing  to  an  acceptable  level  the  confidence  that 
an  inference  drawn  from  the  model  about  the  real  system  will  be  correct. 

6.  Strategic  Planning.  Design  of  an  experiment  that  will  yield  the 
desired  information. 

7.  Tactical  Planning.  Determination  of  how  each  of  the  test  runs 
specified  in  the  experimental  design  is  to  be  executed. 

8.  Experimentation.  Execution  of  the  simulation  to  generate  the 
desired  data  and  to  perform  sensitivity  analysis. 

9.  Interpretation.  Drawing  inferences  from  the  data  generated  by  the 
simulation. 

10.  Irrp lamentation.  Putting  the  model  and/or  results  to  use. 

11.  Documentation.  Recording  the  project  activities  and  results  as 
well  as  documenting  the  model  and  its  use  (Shannon,  1975:23). 

System  definition  and  model  formulation  can  be  achieved  in  several 
ways.  Forrester  suggests  that  the  model  come  first;  that  is,  the 
researcher  normally  has  enough  information  to  construct  a  useful  model. 
He  asserts  that  the  model  will  define  the  data  that  will  be  collected 
(Forrester,  1961; 57). 
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E^nshoff  and  Sisson  suggest  a  flow  approach  to  grasp  a  situation. 
This  entails  breaking  the  system  down  into  a  flow  which  alternates 
between  processing  and  nxDvement.  Once  these  elements  are  identified, 
further  definition  comes  through  observation  and  questioning  (Ehishoff 
and  Sisson,  1970; 65).  Shannon  advocates  that  the  modeler  specify  the 
goals  of  the  system  and  the  boundaries  between  the  system  and  the 
environment  in  order  to  define  the  system.  He  also  suggests  the  use  of 
a  static  model  such  as  a  flow  diagram,  but  cautions  that  the  diagram 
should  include  only  those  elements  that  are  relevant  to  the  study 
objectives  (Shannon,  1975; 26). 

Another  consideration  in  model  formulation  is  that  the  model 
captures  specific  phenomena  or  behavior  that  characterizes  the  system. 
This  structure  is  irrportant  in  determining  any  cause-and-ef feet 
relationships  in  the  model.  Elements  of  this  structure  include  levels, 
flow  rates,  decision  functions,  and  information  channels.  These 
building  blocks  to  model  behavior  may  be  applied  to  models  of  any 
magnitude  (Forrester,  1961; 68-70). 

These  three  elements  are  also  present  in  the  601  process.  Levels 
are  accumulations  within  the  system.  They  may  be  customers  in  a  queue, 
goods  in  transit,  or  information  waiting  to  be  processed.  For  the  601 
process  levels  may  be  represented  by  the  number  of  601s  in  the  system  or 
waiting  to  be  processed  at  some  organizational  level  (Forrester, 
1961:66-70). 

Flow  rates  define  the  present,  instantaneous  flows  between  the 
levels  in  the  system.  Flow  rates  are  often  not  easily  distinguishable 
from  levels,  particularly  when  applied  to  intangible  rates  and  levels 
such  as  information.  Rates  correspond  to  activity,  while  levels  measure 
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the  resulting  state  to  which  the  systein  has  been  broug:.'  as  a  result  of 
flow  rates.  Flow  rates  in  the  601  process  would  be  represented  by  the 
n’jmber  of  60 Is  introduced  into  the  system,  or  the  number  released  by 
some  processing  function  during  a  given  time  period  (Forrester,  19C1; 
68-70). 

Decision  functions  represent  policy  that  determines  how 
information  about  flow  rates  leads  to  decisions.  Decision  functions  are 
responses  to  the  state  of  the  system  that  lead  to  action  in  seme  form, 
such  as  hiring  employees  or  opening  another  teller  line  in  a  bank 
(Forrester,  1961;  68-70). 

Information  is  an  inportant  ingredient  in  determining  flow  rates 
and  levels.  Because  decision  functions  are  dependent  on  information  to 
provide  a  feedback  of  present  rates  and  levels,  information  serves  as  a 
moderator  or  expeditor  in  complex  systems.  Time  relationships  and 
amplification  phenomena  complicate  these  feedback  loops.  Information 
lag  times  and  a  tendency  for  seme  systems  to  exaggerate  information 
inputs  create  surpluses  and  deficits  in  levels  and  flows  that  must  be 
accounted  for  (Forrester,  1961; 68-70). 

Data  Preoaraticn 

Data  preparation  involves  determining  whether  data  are  avaiilable 
to  estimate  the  values  of  parameters  and  constants.  This  includes 
evaluating  the  starting  values  of  all  variables  and  providing  data  with 
which  simulation  outputs  can  be  corpared  for  validation.  Variables 
represent  system  attributes  which  can  take  on  different  values  and  in 
some  way  affect  the  performance  of  the  system.  A  parameter,  on  the 
other  hand,  represents  an  attribute  that  remains  co.nstant  over  all 
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foreseeable  ranges  of  system  operation  (Shannon,  1975;15).  Emshoff  and 
Sisson  note  that  variables  or  parameters  that  affect,  but  are  unaffected 
by,  the  system  are  called  exogenous  factors.  Variables  or  parameters 
whose  values  are  determined  by  other  system  variables  are  called 
endogenous  factors  (Emshoff  and  Sisson,  1970;52). 

Exogenous  and  endogenous  variables  and  parameters  are  further 
defined  as  controllable  or  uncontrollable,  and  static  or  dynamic. 
Exogenous  uncontrollable  variables  must  be  input  to  the  model  to 
represent  the  relevant  parts  of  the  world  that  are  external  to  the 
system.  These  include  such  data  as  frequency  distributions  for  starting 
times.  Dynamic  e.xogenous  variables  might  represent  policies  which 
determine  the  values  of  other  variables,  and  can  be  drawn  from  historic 
or  statistical  data.  Dynamic  endogenous  variables  are  those  that  are  to 
be  predicted  by  the  model,  and  include  performance  measures.  These  may 
have  to  be  estimated  to  provide  starting  data  for  the  model  (Emshoff  and 
Sisson,  1970;52-53). 

Validity  and  Verification 

Perhaps  the  most  important  issue  in  modeling  is  that  of  validity 
and  verifioation.  Cook  and  Russell  describe  a  five-stage  process  for 
establishing  model  validity.  The  first  is  program  testing.  This 
involves  examination  of  the  code  used  to  program  the  model  to  ensure 
that  it  works  as  intended.  This  function  is  also  known  as  verification. 
VaricLble  generation  tests  apply  goodness-of-f it  and  other  parametric  and 
nonparametric  tests  to  both  input  and  output  data  (exogenous  and 
e.ndogenous  variables)  to  ensure  that  variables  for  both  the  model  and 
the  real  system  are  similarly,  if  not  exactly,  distributed.  Another 
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step  in  model  validation  is  si:!jjective  validation.  This  involves  review 
of  the  model's  design  and  output  by  persons  familiar  with  the  real  world 
system,  but  not  involved  in  the  simulation  study.  This  step  judges 
whether  the  model  is  a  reasonable  representation  of  the  real  system 
(Cook  and  Russell,  1989; 606-607) .  Balci  refers  to  this  practice  as 
"face  validity"  (Balci,  1989;66).  The  final  step,  according  to  Cook  and 
Russell,  is  historical  validity.  This  step  conpares  system  input  and 
output  variables  with  documented  performance  variables  of  the  real 
system  to  further  ensure  model  realism  (Cook  and  Russell,  1989;607). 

Balci  further  defines  the  validation  process  by  breaking 
validation  down  into  two  aresis  —  data  validation  and  model  validation. 
Data  validation  determines  whether  model  parameters  and  variables  are 
identified,  measured,  or  estimated  with  sufficient  accuracy.  It  also 
ensures  that  data  transformations  are  performed  correctly  to  ensure  that 
the  model  and  real  system  are  using  the  same  measurement  units.  Model 
validation  differs  from  data  validation  in  that  model  validation  is 
concerned  with  the  accuracy  of  model  logic  and  behavior,  rather  than 
specific  variable  or  parameter  values  (Balci,  1989, ’d?). 

Pidd  discusses  two  types  of  validity:  "black  bo.'c"  validity  cind 
"white  bo.':”  validity.  Black  box  validity  asks  the  question,  "does  the 
model  accurately  reflect  the  real  system?"  Would  someone  involved  with 
the  real  system  accept  the  simulation  as  a  viable  representation  of  the 
real  system?  Black  box  validity  may  be  ccrrplicated  by  the  fact  that  the 
system  being  modeled  has  inherent  flaws  —  hence  the  reason  for  modeling 
to  begin  with.  In  contrast,  white  box  validity  concerns  the  accuracy  of 
the  parameters  used  to  sinrulate  system  events.  White  box  validity  asks 
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the  question,  "do  the  components  of  the  model  represent  knovm  behavior 
and/or  valid  theory  which  exists?"  (Pidd,  1S34;S-10). 

These  principles  will  be  used  in  the  later  development  of  models 
designed  to  experiment  with  the  601  process  as  it  exists,  and  to  compare 
it  with  hypothesized  improvements  to  the  process.  These  principles 
should  lead  to  a  more  accurate,  effective  model  for  testing  the  proposed 
hypotheses . 

Sunrmarv 

This  chapter  has  examined  how  EDI  can  be  an  effective  method  of 
improving  processes  such  as  the  allowance/ authorization  process.  It  has 
discussed  how  EDI,  by  reducing  the  time  and  variability  inherent  in 
paperwork  and  multiple  data  entry  processes,  can  reduce  costs  .id 
improve  operational  effectiveness.  The  search  has  also  evaluated  some 
of  the  characteristics  of  systems  such  as  the  601  process,  and 
established  an  approach  for  modeling  systems  to  capture  some  of  those 
characteristics.  The  next  chapter,  Methodology,  will  outline  the 
approach  taken  to  model  the  601  process  and  the  experimentation  methods 
used  to  evaluate  the  effects  of  EDI  on  the  601  process. 
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III.  Methodology 


Introduction 

The  methodology  used  to  study  the  allowance/authorization  process 
will  be  baused  on  Forrester's  industrial  dynamics  approach  to  systems 
design,  as  well  as  Shannon's  eleven  stages  of  the  simulation  process. 
This  will  include  defining  the  system  and  identifying  key  interactions 
that  result  in  system  problems.  It  will  also  reduce  the  system  to  a 
logic  flow  that  can  be  effectively  modeled  using  corrputer  simulation. 

The  methodology  will  progress  to  identification,  collection  and 
preparation  of  data  used  to  formulate  system  variables  and  parameters. 
The  next  step  will  be  to  validate  the  input  data  to  ensure  that  it  is 
representative  of  actual  system  parameters. 

The  research  will  then  focus  on  the  development  of  a  model  that 
will  validate,  or  fail  to  validate,  the  hypothesis  introduced  in  the 
introductory  chapter.  Another  validation  stage  will  result  from 
completion  of  the  bcisic  model,  this  one  focusing  on  validating  the  model 
eis  a  representation  of  the  actual  system.  The  model’s  success  will  also 
depend  largely  on  the  ability  to  design  experiments  that  will  yield  the 
desired  results.  Once  the  model  has  been  altered  to  facilitate 
experimentation,  it  will  be  executed  in  order  to  draw  inferences 
concerning  system  performance.  These  experiments  will  prove  or  disprove 
the  validity  of  the  guiding  hypothesis  emd  will  provide  some  information 
for  improving  system  performance. 
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Guiding  Hypotheses 


As  mentioned  in  the  introductory  chapter,  the  hypothesis  guiding 
the  research  is  that  the  integration  of  electronic  data  interchange 
(EDI)  into  the  601  process  will  inprove  overall  process  performance  and 
overccme  the  effects  of  varying  input  parameters  by  decreasing  intransit 
times  for  those  601s  that  are  between  activities.  The  measure  of  merit 
in  determining  system  performance  will  be  overall  601  residence  times 
within  the  system.  Residence  times  are  defined  as  being  the  time 
between  601  submittal  at  the  base  level  and  approval  at  WR-ALC. 

Rejecting  or  failing  to  reject  the  hypothesis  will  be  determined 
by  the  differences  in  mean  processing  times  for  the  model  of  the  current 
system  versus  the  mean  processing  times  for  the  model  with  EDI 
integrated  as  a  method  of  trans' erring  the  information  captured  by  the 
601.  Criteria  for  hypothesis  acceptance  will  be  that  a  confidence 
interval  containing  the  mean  processing  time  difference  will  reflect, 
with  a  95  percent  probability,  a  reduction  in  processing  time  for  the 
model  with  EDI  incorporated. 

System  Definition 

The  first  step  in  the  methodology  is  to  identify  the  process  as  it 
exists.  In  addition  to  the  review  of  governing  regulations  framework  as 
it  is  prescribed  to  users  at  all  levels,  the  next  step  will  be  to 
interview  individuals  at  each  step  in  the  process,  from  base  level  to 
final  approval  authority,  in  order  to  get  a  consensus  on  the  structure 
and  behavior  of  the  process  or  processes  as  they  are  perceived. 

Once  the  key  players,  flows,  coordination  loops,  and  decision 
points  in  the  process  are  identified,  the  process  will  be  recreated  in  a 
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flow  diagram.  This  flow  diagram  will  provide  the  framework  around  which 
simulation  code  —  as  well  as  system  variables  and  parameters  —  will  be 
adapted. 

Model  Formulation 

Model  formulaticr  will  involve  translating  the  steps  involved  in 
the  flow  diagram  into  computer  language  in  order  to  mimic  system 
behavior.  GPSS/H  is  the  simulation  language  which  will  be  used  to 
accomplish  this  task.  The  GPSS/H  language  was  chosen  because  its 
structure  permits  it  to  be  learned  in  a  relatively  short  time. 
Additionally,  it  can  handle  fairly  sophisticated  models  on  a  personal 
computer.  This  feature  eliminates  one  of  the  considerations  of  running 
simulation  models  on  large  mainframe  computers  —  the  cost  of  computer 
time. 

The  model  will  be  formulated  to  represent  the  current  system; 
however,  it  may  trivialize  or  bypeiss  altogether  steps  which  are 
determined  to  be  irrelevant  to  system  performance.  Instead,  those  areais 
that  are  deemed  as  critical  bottlenecks,  critical  processes,  or 
potential  governors  of  flow  rates  and  levels  will  be  more  detailed. 

One  assumption  that  will  be  made  in  this  regard  is  that  the  model 
does  not  necessarily  have  to  reflect  the  flow  of  601s  frcm  every  USAF 
base  and  MAJCQM  in  order  to  be  effective.  Representing  each  601  source 
in  the  model  would  drastically  complicate  model  coding  and  complexity, 
as  well  as  dreistically  increase  the  amount  of  data  that  would  have  to  be 
collected  to  develop  effective  model  parameters  and  variables. 
Additionally,  a  global  orientation  may  not  prove  useful  for  exaimining 
flows  between  individual  users  at  levels  below  WR-ALC,  the  convergence 
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point  in  the  process  for  all  USAF  601s.  This  is  an  inportant  point 
since  base-level  and  MAJOQM  vehicle  managers  are  the  primary 
beneficiaries  of  system  success  or  failure. 

A  sinpler,  and  possibly  more  effective  strategy  will  be  to  model 
the  flow  from  the  perspective  of  a  single  base-level  user  submitting 
601s  to  a  single  MAJCQM,  who  in  turn  forwards  those  requests  to  WR-ALC 
and  beyond.  Model  development  and  data  preparation  will  be  accomplished 
according  to  this  assumption. 

The  model  will  also  be  designed  to  facilitate  measurement  of  those 
key  variables  which  characterize  system  performance.  This  will  include 
steps  to  identify  the  independence  of  activities  and  reduce  the  effects 
of  autocorrelation  on  sequential  activities.  It  will  also  include  steps 
to  isolate  those  variables  deemed  most  indicative  of  system  problems. 

With  these  assurrptions  in  mind,  simulation  code  will  be  adapted  to 
the  flow  diagram  to  simulate  the  processes  taking  place  in  the  diagram. 
While  model  parameters  and  variables  will  not  yet  be  defined,  the 
presence  of  the  basic  code  will  dictate  the  tipes  of  questions  which 
need  to  be  asked  in  order  to  obtain  data  to  apply  to  the  code. 

Data  Preparation 

In  order  to  establish  the  range  of  operation  for  the  computer 
code,  data  must  be  collected  from  several  sources  to  get  realistic 
representations  of  system  variables  and  parameters.  These  include 
interarrival  times,  processing  times  at  each  activity  center,  intransit 
times,  feedback  loops  and  other  characteristics  of  system  behavior. 

These  system  variables  and  parameters  will  animate  the  model  in  a 
fashion  which  will  represent  system  activity. 
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Data  preparation  will  require  interaction  with  system  users  at  all 
levels,  not  only  to  ensure  that  the  needed  data  is  identified,  but  also 
to  make  sure  that  the  data  is  valid  as  it  is  applied  to  the  model 
itself.  With  the  single  base/MAJOQM/WR-ALC  flow  assumption  in  mind, 
data  gathering  will  involve  interviews  with  system  users  to  obtain 
either  historical  or  estimated  data  on  which  to  base  model  parameters. 
Some  of  this  data  may  be  obtained  in  the  process  of  defining  the  system, 
but  most  will  follow  the  establishment  of  the  model's  basic  code.  The 
type  of  data  used  will  depend  on  the  degree  of  accurate  historical  data 
that  is  available.  Some  data  may  be  based  on  historical  data,  while 
other  variables  and  parameters  will  be  based  on  estimates  from  managers 
at  using  activities. 

A  conve.ndence  sample  of  four  major  commands  —  MAC,  SAC,  TAC,  and 
AFSC  —  will  be  interviewed  to  get  a  broad  sample  of  perspectives  on 
system  variables  and  parameters.  These  ccnmands  were  selected  based  on 
the  wide  range  of  missions  that  they  represent,  as  well  as  their  large 
and  relatively  stable  fleet  sizes.  Additionally,  CO-IUS  bases  were 
chosen  to  simplify  data  gathering,  as  well  as  to  avoid  large 
fluctuations  in  601  mailing  times  that  might  be  e.xperienced  between 
overseas  ccnmands,  their  subordinate  units,  and  WR-ALC.  Interviews  will 
be  directed  at  MAJCOM  CEl^,  the  persons  who  actually  process  and 
distribute  the  601s  at  the  MAJCOi  level . 

Interviews  will  also  include  a  sample  of  at  least  two  bases  per 
MAJCCK  interviewed.  These  will  be  chosen  to  again  get  a  broad 
perspective  of  mission  types  and  fleet  sizes  within  the  command,  i.e.  a 
bomber  and  a  missile  base,  a  large  and  a  small  base,  etc.  Interviews 
there  will  focus  on  the  Fleet  Mainagement  Sections  or  base  Vehicle 
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Operations  Branches,  They  are  the  individuals  who  coordinate  and  sufcnut 
601s  at  the  base  level. 

Finally,  additional  data  will  be  gathered  frcm  the  Support 
Equipment  Division  at  Warner  Robins  Air  Logistics  Center  (WR-ALC) ,  the 
approval  authority  for  vehicle  allowance/authorization.  In  addition  to 
providing  quantitative  data  on  system  parameters,  these  interviews  will 
explore  other  aspects  of  system  behavior  and  performance  such  as: 

1.  Process  ownership.  What  agency  has  overall  responsibility  for  the 
implementation  and  effectiveness  of  the  process? 

2.  Process  inputs.  What  agencies  have  inputs  to  the  process? 

3.  Process  flows.  What  are  the  paths  and  loops  followed  by  entities 
within  the  process? 

4.  Process  visibility.  To  what  extent  do  system  users  have  access  to 
entity  status? 

5.  Process  constraints.  What  resources  or  conditions  constrain  the 
capacity  of  the  process? 

6.  Measures  of  merit.  By  what  standard  or  standards  should  process 
effectiveness  be  measured?  What  constitutes  "good”  system  performance? 

7.  Costs  and  benefits.  What  are  the  costs  or  benefits  of  good  or 
bad  system  performance? 

These  elements  will  help  to  finalize  model  formulation  and  will 
complement  the  quantitative  data  used  to  define  model  parameters. 

An  inportant  note  to  be  made  at  this  point  is  that  the  nature  of 
the  sampling  used  will  not  permit  the  research  to  make  scientific 
conclusions  about  the  effectiveness  of  EDI  on  the  601  process  at  every 
management  level.  The  experimentation  will  instead  provide  some  insight 
into  the  results  that  might  be  expected  given  an  EDI -integrated  601  flow 
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with  the  parameters  that  were  used.  In  order  to  draw  scientific 
conclusions,  the  parameter  and  variable  data  populations  would  have  to 
be  compared  with  the  overall  USAF  populations  using  Chi-Square  or  other 
goodness-of-fit  tests  to  determine  if  the  data  do  indeed  come  from  the 
same  populations.  Such  an  exercise  would  be  extremely  corrplex  and  time- 
consuming,  and  may  not  be  necessary  to  make  useful  inferences  about  the 
effects  of  EDI  on  the  601  process. 

Validation 

Model  validation  will  be  patterned  after  Pidd's  white  and  black 
box  validation  stages.  White  box  validity  will  concern  the  accuracy  of 
the  model's  coding  to  ensure  that  it  carries  out  the  desired  model 
logic.  Black  box  validity  will  concern  making  sure  that  the  model  logic 
reflects  actual  system  performance.  Flow  chart  ccmparison  and  further 
user  interrogation  will  accorrrolish  this  task.  White  box  validity  will 
involve  extensive  use  of  model  debugging  and  visual  checks  to  ensure 
that  the  coding  is  correct.  Black  box  validity  will  entail  the  "face 
validity"  described  by  Emshoff  and  Sisson  in  which  the  system  users  give 
inputs  concerning  the  accuracy  of  the  model.  It  will  also  involve 
corroaring  the  model's  output  data  against  any  existing  system  historical 
data  to  further  validate  the  model. 

Strategic  Planning 

Strategic  planning,  as  defined  by  Shannon,  involves  designing  the 
experiment  to  facilitate  measurement.  In  order  to  test  the  effects  of 
EDI  on  the  system,  the  ntxlel  will  be  structured  so  that  measurements  can 
be  taken  at  key  delay  points  to  determine  delay  duration.  Additionally, 
total  system  time  will  be  measured  to  test  the  effects  of  EDI  on  601 
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total  process  times.  The  objective  in  this  portion  of  the  experiment 
will  be  to  determine  if  EDI  reduces  system  response  time  by  reducing 
intransit  times  between  activities. 

First,  a  GPSS/H  model  will  be  constructed  which  imitates  the 
processes  inherent  in  the  current  system.  Another  model  will  then  be 
constructed  to  reflect  a  proposed  system  which  incorporates  EDI  as  a 
means  of  transmitting  the  inforration  normally  carried  on  the  form  601. 
An  important  note  here  is  that  faster  transmittal  times  inherent  in  EDI 
will  be  the  primary  focus  of  later  experimentation.  Other  features  such 
as  irrproved  accuracy  and  faster  processing  may  be  mentioned,  but  will 
not  be  \ised  to  support  the  .  .search  hypothesis.  These  faster 
transmittal  times  can  be  easily  simulated  within  the  second  model  by 
changing  the  variables  that  represent  entity  advance  times  from  one 
activity  to  another. 

Tactical  Pla.nnina  and  Experimentation 

Test  runs  in  the  model  will  be  replicated  enough  times  to  get  a 
statistically  significant  number  of  output  samples  with  which  to  make 
comparisons  with  the  actual  system  and  base  model .  For  each  of  the 
runs,  random  number  streams  will  be  changed  for  processes  that  generate 
random  numbers  to  ensure  independence  of  each  replication,  and  to 
facilitate  synchronization  of  the  two  models.  This  step  is  important  to 
ensure  that  differences  in  system  residence  times  reflect  the  reduced 
intransit  times,  and  not  variations  in  other  system  activities. 
Additionally,  runs  will  include  an  initialization  period  sufficient  to 
overcame  the  effects  of  initialization  bias  in  order  to  observe  the 
system  in  its  normal,  steady-state  behavior. 
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Interpretation 


Once  the  model  has  been  modified  and  executed  to  simulate  the 
effects  of  EDI,  sufficient  output  data  will  exist  to  draw  inferences 
about  system  performance.  Schriber  suggests  the  use  of  a  correlated 
paired-t  test  to  compare  the  performance  of  alternative  systems.  This 
test,  along  with  the  use  of  assigned  random  number  streams  throughout 
the  model,  uses  matched  pairs  of  numbers  to  block  out  the  effects  of 
uncontrol ladjle  variables  such  as  process  times  and  transaction  routing. 
By  matching  pairs  of  data  frcm  the  two  models,  each  can  be  ccnpared 
based  on  the  effects  of  intransit  times  alone,  with  all  other  factors 
being  equal  (Schriber,  1991:  339-340). 

Computing  the  paired  differences  of  the  data  will  cancel  out  the 
effects  of  the  uncontrollable  factors.  By  working  with  matched  pairs,  a 
positive  correlation  is  established  between  the  maribers  of  each  matched 
pair  in  order  to  reduce  the  variability  in  paired  differences  and 
sharpen  the  contrast  between  the  alternative  systems.  This  method  will 
be  used  to  determine  the  differences  in  residence  times  between  the  two 
models  (Schriber,  1991:  339-340). 

To  execute  the  paired-t  test,  average  residence  times  from  each 
run  of  the  base  (without  EDI)  model  will  be  paired  with  the 
corresponding  average  residence  times  of  the  experimental  (with  EDI) 
model.  The  differences  in  these  times  will  be  averaged  for  all  of  the 
runs,  and  paired  difference  confidence  intervals  obtained  to  estimate 
the  true  mean  of  that  difference.  The  formula  for  obtaining  the 
confidence  interval  is: 
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(1) 


Fit 

where 

Fp  =  mean  difference 

t,/2  *  1.833  for  a  95%  confidence  interval 
Sp  =  sample  standard  deviation 
n  “  sample  size 

The  confidence  interval  will  contain  a  pair  of  numbers,  one 
representing  the  lower  limit  and  the  other  representing  the  upper  limit 
of  the  range  in  which  the  true  mean  should  lie  given  the  alpha 
(probability)  used.  If  the  confidence  interval  of  the  difference  in 
mean  residence  times  between  the  two  models  does  not  span  zero,  it  can 
be  concluded  that  the  inclusion  of  EDI  into  the  process  improves  process 
times  for  this  experiment. 

If  time  savings  are  deemed  to  be  small  or  nonexistent,  further 
experimentation  may  be  conducted  to  see  how  flow  rates,  queue  sizes,  and 
other  factors  have  been  affected  by  the  inclusion  of  EDI.  This  may 
identify  shortcomings  or  bottlenecks  that  may  not  be  irtproved  by  EDI. 

Conclusion 

The  results  of  this  study  will  support  or  refute  the  effectiveness 
of  EDI  as  a  means  of  inproving  system  performance  and  will  provide  some 
measure  of  the  effects  of  management  decisions  on  the  flow  of  601s 
through  the  system.  This  information  will  serve  as  a  starting  point  for 
process  modifications  which  will  improve  its  responsiveness  to  users  at 
all  levels. 
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The  next  chapter.  Model  Development  will  provide  an  overview  of 
the  GPSS/H  simulation  language,  and  will  describe  the  code  that  is  used 
to  represent  the  various  activities  occurring  in  the 
al lowance/authorization  process.  It  will  also  discuss  the 
considerations  which  went  into  the  development  of  each  model,  and  will 
address  the  application  of  the  variables  and  parameters  that  were 
derived  from  interviews  with  process  users. 
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IV.  Model  Development 


Introduction 

As  mentioned  in  chapter  III,  the  simulation  model  wais  developed 
with  Forrester's  industrial  dynamics  approach  and  Shannon's  eleven 
stages  of  model  development  in  mind.  The  steps  included  defining  the 
system,  capturing  the  critical  system  processes  into  a  flow  diagram,  and 
interpreting  the  flow  diagram  into  computer  language  which  could 
facilitate  simulation  of  the  actual  and  experimental  systems.  They  also 
involved  obtaining  data  to  replicate  the  variadales  and  parameters  in  the 
actual  system,  validating  both  the  flow  diagram  ("black  box"  validity) 
eind  the  computer  code  used  to  mimic  the  system  ("white  box"  validity), 
and  developing  an  output  format  which  would  enable  statistical 
comparison  of  model  alternatives. 

Additional  considerations  in  developing  the  model  included 
simplicity  of  design,  ease  of  modification,  construction  which  would 
facilitate  measuring  statistics  of  interest  with  respect  to  system 
performance,  and  synchronization  of  steps  in  competing  models  to 
eliminate  the  effects  of  controllable  variables.  Simplicity  of  design 
was  necessary,  both  to  accorrmodate  effective  troubleshooting  and  to 
allow  validation  by  users  who  may  not  be  familiar  with  simulation 
language.  Ease  of  modification  was  a  prerequisite  to  p)ermit  adjustments 
for  the  various  experiments  to  be  p>erformed  using  the  same  basic  model 
framework.  Finally,  the  model  had  to  be  constructed  so  that  statistics 
on  system  residence  times,  queue  sizes,  auid  flow  rates  could  be 
effectively  megisured. 
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Capturing  the  Flow 


After  the  boundaries  of  the  process  were  identified,  the  flow  of 
the  601  process  had  to  be  defined.  This  included  determining  the  601 
input  source,  intransit  channels,  decision  and  processing  points, 
coordination  loops,  auid  output  points.  Following  interviews  with 
vehicle  managers  at  base  level  and  MAJOQMs,  and  equipment  managers  at 
WR-ALC,  a  flow  diagram  was  developed  which  would  permit  visualization  of 
key  model  processes  (see  Appendix  A).  This  flow  diagram  became  the 
direct  source  from  which  computer  code  could  be  adapted  for  later 
simulation  models. 

The  flow  chart  uses  standard  flow  symbols  to  denote  input  points, 
activity  points,  decision  points,  document  initiation,  and  process 
routing.  The  chart  actually  begins  with  activities  which  lead  up  to  the 
initiation  of  the  601.  Although  these  activities  are  not  part  of  the 
process  to  be  modeled,  their  inclusion  in  the  flow  chart  helps  to 
provide  a  broader  picture  of  the  boundaries  of  the  process  and  the 
events  which  generate  process  inputs. 

The  first  segment  of  the  chart  describes  base  level  activities 
which  generate  a  601  submission.  The  parallelogram  represents  the 
users'  identification  of  the  need  for  vehicle  support.  This  symbol 
denotes  an  input  into  the  system.  From  there,  those  users  must 
coordinate  the  requirement  with  the  vehicle  operations  branch,  an 
activity  point  represented  here,  and  henceforth  in  the  chart,  by  a 
square  or  rectangle.  Vehicle  operations  branch  personnel  determine  if  a 
new  authorization/al lowance  is  needed  to  support  the  requirement.  This 
determination  is  a  decision  point  represented  by  a  diamond.  If  the 
request  does  require  a  new  authorization/al lowance,  the  process 
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continues  with  preparation  of  an  form  601.  If  an  open 
authorizat ion/ allowance  already  exists,  branch  personnel  may  take  action 
to  obtain  a  vehicle  asset  to  fill  the  slot  without  initiating  a  new  601 
(Johnson,  1990). 

The  second  group  of  symbols  includes  those  which  describe 
activities  that  taike  place  once  the  request  has  been  approved  at  base 
level  and  a  601  heis  been  prepared  and  submitted  to  the  MAJOCM  vehicle 
manager  (CEMO) .  Once  the  CEMO  receives  and  evaluates  the  document,  the 
first  decision  point  determines  whether  the  form  is  properly  docmented 
with  the  appropriate  codes  and  request  justification.  If  the  form  does 
not  contain  the  proper  administrative  requirements,  the  CEMO  coordinates 
with  the  submitting  unit  to  correct  the  deficiencies.  If  all 
administrative  requirements  have  been  met,  the  request  is  evaluated 
against  the  current  corrmand  vehicle  authorization  listing  (VAL),  and 
against  mission  urgency  to  determine  if  the  need  for  the  vehicle 
warrants  a  new  authorization/allowance  in  light  of  cotimand  vehicle 
ceilings.  If  the  need  is  properly  justified  and  the  ccrrmand  ceiling 
will  not  be  exceeded,  the  CEMO  may  approve  the  new  authorization  at  his 
or  her  level.  If  the  cormand  ceiling  would  be  exceeded  by  the  new 
authorization,  the  CEMO  must  decide  if  he  or  she  wishes  to  delete  an 
authorization  elsewhere  in  order  to  acccrrmodate  the  new  authorization. 
E)ach  of  these  decisions  are  represented  in  the  chart  by  diamonds,  and 
the  outcomes  are  once  again  represented  by  rectangles  (Johnson,  1990). 

The  CEMO  must  also  determine  if  a  new  allowance  is  required  by 
reviewing  the  appropriate  Table  of  Allowances  for  the  requesting 
activity.  The  outcome  of  this  evaluation  detennines  whether  the  601 
requires  further  coordination.  If  no  new  allowance  is  required,  the 
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CEMO  can  approve  or  disapprove  the  authorization  and  no  further  action 
is  required.  If  a  new  allowance  is  required,  the  CEMO  must  forward  the 
601  to  WR-ALC/L2E,  Air  Force  Support  Equipment  Division,  for  further 
evaluation  (Johnson,  1990). 

A  third  group  of  symbols  describes  activities  which  take  place  at 
WR-ALC,  if  the  601  requires  action  at  this  level.  First,  the  Support 
Ekjuipment  Division  must  determine  if  the  request  requires  further 
coordination  based  on  specialized  needs  which  must  be  assessed  by  the 
appropriate  ALC  Item  Manager.  If  not,  the  Support  Equipment  Division 
can  approve  or  disapprove  the  601  according  to  the  strength  of  the 
justification  or  other  factors.  Otherwise,  a  copy  of  the  601  is  mailed 
to  the  Item  Manager  who  is  familiar  with  the  mission  and  requirements  of 
the  requesting  activity.  The  Item  Manager  makes  an  input  to  the  support 
equipment  division,  who  approves  or  disapproves  the  request  based  on 
that  input  (Johnson,  1990). 

A  final  loop  describes  the  possibility  that  the  request  will 
represent  a  new  equipment  requirement  that  does  not  have  a  previously- 
assigned  national  stock  number.  Once  this  loop  has  been  accorplished  or 
bypassed,  the  Support  Equipment  Division  must  decide  if  the  new 
allowance  would  exceed  ceilings  for  the  requesting  activity.  Again,  an 
existing  allowance  must  be  deleted  if  the  new  allowance  would  exceed  the 
ceilings.  If  the  Support  Equipment  Division  aurees  that  the  new 
allowance  should  be  added,  the  601  will  be  approved  and  the  requesting 
command  notified  so  that  they  can  taike  action  —  either  through  the 
vehicle  priority  buy  or  in-comrrand  rotation  —  to  fill  the  new 
authorization/allowance.  This  action  completes  the  601  process  as  it 
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pertains  to  authorization/allowance  requests,  ='xid  defines  the  end  of  the 
flow  diagra'n  (Johnson,  1990). 

The  diagram  was  mailed  to  WR--_,C/LZE  for  excunination,  a  step  which 
constitutes  black  box  validity  of  the  model.  AFSED  personnel  agreed 
with  the  flow  diagram  as  a  functional  interpretation  of  the  process, 
thus  settinr  the  stage  for  adapting  ccrputer  code  to  facilitate 
simulation  of  the  process  (Johnson,  1991). 

Development  of  Computer  Code 

Using  the  flowchart  as  a  teirplate,  ccrputer  code  wais  adapted  to 
mimic  the  activities  occurring  in  the  601  process.  GPSS/H,  a  ccrrputer 
simulation  language,  was  selected  to  facilitate  experimentation  with  the 
601  process  and  to  collect  information  on  process  performance. 

The  GPSS/K  Simulation  Language.  The  GPSS/H  simulation  language  is 
an  effective  method  of  mimicking  the  behavior  of  discrete  systems.  It 
allows  the  researcher  to  simulate  dynamic  processes  and  to  measure  key 
indicators  of  system  performance  such  as  resource  utilization  rates, 
queue  sires,  residence  times,  and  a  host  of  other  statistics  of 
interest.  The  GPSS/H  modeler  views  the  system  being  modeled  frem  the 
perspective  of  entities  moving  through  the  system.  These  entities, 
called  transactions  (abbreviated  XACTs),  are  envisioned  as  moving 
through  the  system  from  block  to  block,  with  each  block  representing  an 
action  or  process  being  performed  on  the  entities.  Once  the  program 
ccrpiles  the  code,  a  START  statement  begins  the  flow  of  transactions 
into  the  system  (Banlrs  and  others,  1989:7-13). 

The  portion  of  a  GPSS/H  model  which  represents  the  activity  flow 
is  made  up  of  block  statements.  These  consist  of  a  GPSS/K  corrmand 


4-5 


followed  by  a  series  of  alphanumeric  characters  known  as  operands.  The 
function  of  each  operand  varies  with  the  conmand,  but  in  general  serves 
as  a  variable  or  parameter  which  defines  the  duration,  frequency, 
routing,  or  distribution  of  the  activity  being  performed  upon  each 
transaction  (Banks  and  others,  1989:23-24). 

For  the  model  being  studied,  each  transaction  is  representative  of 
a  601  somewhere  in  the  process.  A  GENERATE  block  represents  the 
submission  of  a  601  at  base  level.  For  exarrple,  the  GPSS/H  block 
GENERATE  RVE>:PO(  2,12) 

represents  601s  being  submitted  according  to  an  exponential  distribution 
with  a  mean  of  twelve,  with  the  deviation  from  that  mean  determined  by  a 
current  random  number  from  random  number  stream  two  (more  will  be 
discussed  about  random  number  streams  at  a  later  point)  (Banks  and 
others,  1939:25,249). 

GEI'^ERATE  blocks  can  also  specify  the  duration  of  a  particular 
model  run.  The  model  can  be  run  until  a  specified  number  of 
transactions  are  TERMII'IATEd ,  or,  as  in  this  model,  until  a  specified 
amount  of  time  units  has  elapsed.  In  this  model,  the  block 
GEInERATE  730 

is  placed  at  the  end  of  the  block  statements  to  tell  the  ccnputer  to  run 
the  model  for  730  days  (two  years)  (Banks  and  others,  1989:25). 

GPSS/H  also  lias  blocks  that  can  represent  the  time  delay  of  an 
activity  being  performed.  The  ADVANCE  blocks  in  this  model  represent 
processing  times  by  MAJOQM,  WR-ALC,  Item  Manager,  and  CASC  activities, 
as  well  as  the  intransit  times  in  between  each  of  these  activities.  For 
exanple,  the  block 
ADVAIvCE  7 
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would  represent  a  process  requiring  seven  days  (tine  segments  are 
recorded  as  days  for  this  model,  although  minutes,  hours,  or  other  time 
measurements  may  be  used)  to  canrplete.  Because  601s  represent  temporary 
entities  in  the  request  process,  they  are  TElWINATEd  at  the  end  of  the 
process  as  they  are  either  approved  or  disapproved  (Banks  and 
others, 1989: 26-28). 

Other  blocks  within  GPSS/H  represent  resources  with  limited 

capacity.  The  model  was  developed  with  blocks  labeled  CE2>iO,  ROBINS, 

ITEMMGR,  and  GASC  to  represent  these  facilities,  as  they  are  termed  in 

GFSS/K  simulation  language.  SEIZE  and  RELEASE  blocks  represent 

transactions  entering  and  leaving  facilities.  Before  a  transaction  can 

enter  a  facility,  it  must  SEIZE  it.  Once  the  facility  is  finished 

processing  a  transaction,  it  RELEASES  it,  indicating  that  the  required 

processing  time  has  elapsed  for  that  transaction.  For  this  model,  only 

one  transaction  can  occupy  any  facility  at  one  time;  therefore,  a 

transaction  cannot  SEIZE  a  facility  until  the  previous  transaction  has 

been  processed  eind  RELEASEd.  For  example,  the  combination 

SEIZE  CEMO 
ADVAInCE  7 
RELEASE  CEMO 

would  represent  a  601  being  received  by  the  MAJCQM  Corrmand  Equipment 
Management  Office,  requiring  seven  days  to  process  for 
approval /disapproval ,  and  then  being  released  for  further  coordination 
or  returned  to  the  submitting  organization  (Banks  and  others,  1989:28- 
30). 

Ccnnplements  to  the  SEIZE  block  are  the  QUEUE  and  DEPART  blocks. 
These  are  bracketed  around  the  SEIZE  blocks  and  provide  a  holding  place 
for  transactions  waiting  to  be  SEIZEd  by  a  facility.  They  also 
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facilitate  iirportant  measurerents  of  flow  rates  such  as  queue  sizes.  By 

using  the  canbination 

CtJEUE  MAJOR 
SEIZE  CtMO 
DEFAFvT  MAJOR 

measurements  can  be  taken  on  the  current,  average,  or  maximum  number  of 
transactions  waiting  to  SEIZE  the  facility  named  CEMO  (Banks  and  others, 
1989:91-93). 

Other  blocks  are  also  used  to  facilitate  the  simulation  of  601s 

moving  through  the  system.  The  FTJI'fCTICX'}  block  specifies  the  probability 

that  a  particular  transaction  will  be  assigned  a  value  which  is  used 

later  for  routing  to  non-sequential  blocks  or  other  deterministic 

activities.  The  FUNCTION  blocks 

MAJCO  FUNCTIOis  RN2,D2 
0.05,1/1.0,2 

determine  that  five  percent  of  the  transactions  entering  the  block  will 
be  assigned  a  value  of  1,  and  the  rest  will  be  assigned  a  value  of  2. 

In  this  case  the  assignment  is  based  on  a  random  number  frcm  random 
number  stream  two,  and  is  a  discrete  function  with  the  distribution 
divided  among  two  ranges  (0-.05,  and  .05-1.0)  (Banlcs  and  others, 
1989:246-248). 

Once  the  FUI4CTICX4  block  has  cis.signed  a  value  to  a  particular 
transaction,  a  TEST  block  can  be  used  to  determine  the  value  or  status 
of  that  transaction  and  route  the  transaction  accordingly.  For  exanple, 
the  block 

TEST  E  FI'i(MAJCO) ,  2  ,OUT 

determines  the  status  of  the  trcinsaction  which  has  been  assigned  a  value 
by  the  function  labeled  MAJCO.  If  the  transaction  has  been  assigned  a 
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value  equal  to  2,  it  will  proceed  to  the  next  sequential  block, 
otherwise,  it  will  be  routed  to  the  block  laibeled  OUT.  In  this  model, 
the  combination 

MAJCO  FuI'JCTia'I  RI'i2,D2 
0.05,1/1.0,2 

TEST  E  FTh (MAJCO)  ,2, OUT 

simulates  the  event  that  five  percent  of  the  601s  received  by  the  MAJCCM 
CEHO  are  disapproved  (and  routed  out  of  the  system),  and  the  remaining 
95  percent  proceed  for  further  evaluation  (Banks  and  others,  1989:136- 
137). 

Still  other  GPSS/H  blocks  permit  effective  statistical  evaluation 
of  the  model's  output.  The  RMULT  block  is  a  control  statement  that 
specifies  a  new  offset  into  the  designated  random  number  stream  for  each 
model  replication.  This  allows  variation  in  generation  frequencies, 
advance  times,  and  other  stochastic  activities  for  each  replication  in 
the  model.  Another  command,  the  RESET  block,  sets  all  transaction 
statistic;'  to  zero  following  an  initialization  run,  but  does  not  remove 
current  transactions  from  the  model.  This  permits  the  experimentation 
to  begin  at  a  point  at  which  the  process  is  already  operating  at  steady 
state,  rather  than  starting  with  enpty  facilities  and  waiting  for  them 
to  became  active.  Beginning  the  simulation  at  other  than  steady  state 
could  affect  the  statistical  accuracy  of  the  model  (Banlts  and  others, 
1989:211-217,  244-245). 

Another  set  of  control  statf:ients  facilitates  multiple  model  runs. 
The  and  EITODO  statements  are  run-control  statements  that  form  a  loop 
which  executes  the  model  repeatedly  for  a  nurber  of  replications 
specified  by  an  index  variable  in  the  DO  statement.  Once  the  specified 
number  of  executions  has  been  accorrplished,  the  EI'TDDO  statement 
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discontinues  the  loop  and  the  rrodel  stops  running.  For  example,  the 
combination 
DO 

START  1 
RESET 
START  1 
ENDDO 
END 

performs  a  series  of  10  replications  of  the  model,  each  consisting  of  an 
initialization  period,  followed  by  a  second  run  for  effect  in  which  the 
RESET  statement  has  removed  al  1  statistics  from  the  model ,  but  not  the 
transactions.  The  DO  loop  variables  consist  of  an  integer 
anpervariable,  &I,  which  can  take  on  a  number  of  values.  It  is 
incremented  each  time  the  model  is  executed.  When  its  value  equals  that 
of  the  second  operand,  the  EInDDO  statement  is  executed,  and  the  model 
stops  (Banks  and  others,  1989:227-228). 

Finally,  PUTPIC  statements  can  be  used  to  print  output  statistics 
of  interest  into  a  specified  output  file.  This  permits  the  modeler  to 
obtain  customized  reports  using  GPSS/H  Standard  Numeri cal  Attributes 
(SNA's),  codes  which  specify  particular  statistics  about  transactions, 
facilities,  or  queues.  The  SNA  Ml,  for  example,  when  included  in  a 
PUTPIC  statement,  would  collect  the  system  residence  times  of  each 
transaction  and  print  it  into  a  file  (Banks  and  others,  1989:171-173). 

In  strrmary,  GPSS/H  simulates  entities  moving  through  a  system, 
each  competing  for  scarce  resources.  Once  the  code  is  compiled,  a  START 
statement  initiates  the  model ,  and  a  GENERATE  statement  introduces 
transactions  into  the  model  at  specified  intervals.  E^ch  transaction 
ADVANCEls  through  the  model,  SEIZES  facilities  representing  scarce 
resources,  is  routed  using  FUNCTIONS  and  TEST  statements,  and  TERMINATES 
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when  it  has  corpleted  its  aissigned  route.  DO  and  EM)DO  statements  form 
control  loops  that  permit  multiple  replications,  and  PUTPIC  statements 
print  specified  information  to  files.  Additionally,  GPSS/K  features 
SNAs  which  collect  measurements  of  interest  concerning  the  behavior  of 
the  system.  Although  some  of  these  commands  —  and  nunnerous  other 
GPSS/H  commands  which  have  not  been  mentioned  —  have  other  uses  within 
GPSS/H,  the  commands  mentioned  will  be  used  to  simulate  the  flows  and 
loops  inherent  in  the  601  process. 

Development  of  Model  Variables  and  Parameters.  Although  GPSS/H 
code  provides  a  static  framework  around  which  the  model  is  formulated, 
the  adaptation  of  data  to  that  code  animates  the  model  in  a  faishion 
which  converts  the  code  to  a  series  of  variables  and  parameters. 
Activities  which  remain  constant  over  the  foreseeable  range  of  system 
operation  are  parameters,  while  those  that  take  on  different  values 
during  the  process  are  variables.  These  variables  and  parameters  define 
the  simulation  operation  and  give  life  to  the  model. 

In  order  to  define  those  variables  and  parameters,  each  block  of 
GPSS/H  code  is  followed  by  one  or  more  operands  which  specify  the 
stochastic  distributions,  frequencies,  ranges,  and  durations  of  those 
activities.  While  the  GPSS/H  statements  alone  can  reflect  those 
activities  being  carried  out  by  the  flow  diagram,  the  operands  animate 
the  code  to  reflect  the  time  and  interval  realities  within  the  system. 

In  order  to  develop  operands  which  would  accurately  define  system 
variables  and  parameters,  some  questions  had  to  be  answered.  These 
questions  included: 

1.  How  often  are  601s  submitted? 

2.  What  is  the  distribution  of  interarrival  times? 
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3.  What  is  the  intransit  time  between  each  proc.-ssing  point? 

4.  How  long  does  each  process  take? 

5.  What  is  the  percentage  of  601s  tha  are  approved/ disapproved  at 
each  processing  point? 

6.  What  percentage  require  coordination  outside  the  normal  flow  loop? 

Interrogation  began  at  the  bcise  level.  Two  beises  were  chosen  from 

each  of  the  following  cotimands:  SAC,  MAC,  TAC,  and  AFSC.  Each  base  was 
interviewed  to  determine  1)  the  average  nunriber  of  601s  suhnnitted  in  a 
year,  and  2'  the  estimated  intransit  nailing  time  between  the  base  and 
its  serving  MAJOOM.  The  first  question  was  in .ended  to  provide  the 
source  variable  for  transactions  entering  the  model.  Although  sane  of 
the  bases  had  historical  data  pertaining  to  the  number  of  601s 
generated,  sane  were  estimates.  Becavise  the  interarrival  times  (time 
between  submissions)  was  assumed  to  be  exponential  in  nature  (see 
explanation  on  page  4-14,  4-15),  a  mean  interval  was  determined  fron  the 
data  provided  from  the  eight  bases.  This  value  was  used  as  an  operand 
for  the  initial  GEIIERATE  stater.ient ,  and  thus  established  the  flow  rate 
for  the  model .  Al 1  of  the  intransit  times  to  the  serving  MAJCCMs  were 
estimates  provided  by  the  users.  They  were  averaged  to  obtain  an 
operand  for  the  ADVANCE  block  between  the  base  level  and  MAJCOM 
processing  points. 

As  mentioned,  four  MAJOQMs  were  interviewed  to  determine  parameter 
and  variable  values  for  model  code  corresponding  to  MAJCCM  activities. 
Questions  concerned  1)  percentage  cf  601s  disapproved  at  the  MAJCOM 
level,  2)  average  MAJCOM  601  processing  time,  and  3)  average  intransit 
mail  time  to  WR-ALC.  The  percentage  disapproved  at  the  MAJCOM  level  was 
used  to  determine  the  FUNCTION  ranges  at  MAJCOM  decision  points.  The 
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average  601  processing  time  provided  the  operand  for  the  MJVANCE 
statement  used  to  represent  MAJCXM  601  processing  times.  Finally,  the 
average  intransit  mail  time  vrais  needed  to  determine  the  operand  value 
for  the  ADVANCE  statement  representing  mail  time  between  MAJOCM  and  WR- 
ALC  decision  points. 

WR-ALC  was  the  highest  level  at  which  parameter  and  variable 
figures  were  garnered.  Similar  to  the  questions  posed  to  the  MAJOCM 
were  questions  determining  1)  the  average  length  of  time  required  to 
process  each  601,  as  well  as  process  times  from  Item  Managers  (IM)  and 
CASC,  2)  the  percentage  of  601s  that  must  be  coordinated  with  IMs  and 
CASC,  3)  the  percentage  of  601s  that  are  disapproved  by  WR-ALC  and  IMs, 
and  4)  the  intransit  mail  time  between  WR-ALC  and  IM  emd  CASC 
coordination  points. 

Appendix  B  contedns  a  summary  table  of  figures  obtained  from  each 
agency  in  response  to  interview  questions  asked.  The  values  for  each 
base  were  averaged  to  obtedn  variable  and  parameter  figures  for  a 
simulated  base  submitting  601s.  Similarly,  values  obtained  from  the 
four  MAJCCMs  interviewed  were  averaged  to  derive  variables  and 
parameters  for  MAJCOM  activities  in  the  model .  Because  WR-ALC  is  the 
single  point  into  which  all  601s  flow  in  both  the  actual  system  and  in 
the  model ,  the  figures  obtained  for  that  agency  were  not  modified.  The 
figures  obtained  from  each  level  were  plugged  into  the  appropriate 
operands  of  the  corresponding  GPSS/H  block  statements  representing  that 
activity. 

For  system  processing  times,  an  exponential  distribution  is 
aissumed.  Not  only  is  this  distribution  ccrmonly  used  in  simulation 
models  to  reproduce  activity  times,  but  is  preferred  in  this  case  over  a 
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normal  distribution  because  of  the  possibility  that  a  normal 
distribution  can  return  negative  numbers  unless  the  standard  deviation 
of  the  mean  is  at  least  5.  This  phenomenon  of  GPSS/H  models  made  lose  of 
the  normal  distribution  undesirable  for  this  model.  Use  of  the 
exponential  distribution  is  further  substcintiated  by  McClave  and  Benson, 
who  note  that  the  interarrival  times  to  many  real  queues  can  be 
reasonably  approximated  by  an  exponential  probability  distribution. 

They  also  note  that  the  exponential  distribution  has  proved  to  be  an 
adequate  approximation  to  the  time  required  to  service  a  customer. 

Thus,  the  exponential  distribution  can  be  used  to  describe  both  the 
input  source  and  the  service  mechanism  (McClave  and  Benson,  1988:287). 
The  601  process  is  closely  analagous  to  a  servicing  process,  because  of 
the  queues,  flows,  and  processing  activities  involved. 

Model  and  Experiment  Planning.  The  addition  of  interview  data 
into  the  block  statement  operands  conpleted  the  flow  logic  portion  of 
the  model;  however,  additional  control  statements  euad  other 
considerations  were  necessary  to  facilitate  the  use  of  the  model  as  a 
tool  for  comparing  system  alternatives.  Three  primary  considerations 
were  involved  in  model  planning  —  model  synchronization,  statistical 
effectiveness,  and  data  output. 

Because  the  experiment  actually  consisted  of  two  separate  GPSS/H 
models  —  one  representing  the  actual  system  and  one  modified  to  reflect 
the  reduced  intransit  times  resulting  from  the  introduction  of  EDI  —  it 
was  necessary  to  ensure  that  the  dif ferery.'es  in  601  system  residence 
times  actually  resulted  from  the  reduced  intransit  times  and  not  from 
stochastic  variations  in  other  process  activities.  This  wais 
accorrplished  by  specifying  the  random  number  streams  in  each 
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stochastically-controlled  statement  in  order  to  synchronize  the  steps  in 
the  corrpeting  models. 

GPSS/H  simulations  are  stochastic  in  nature.  They  use  random 
variables  to  simulate  variations  in  the  interarrival  times  of  GKNEkATE 
blocks,  the  service,  intransit,  or  processing  times  in  ADVMCE  blocks, 
and  to  aissign  transactions  to  frequeicy  distributions  in  HJNCTIC»i 
blocks.  To  generate  these  random  variables,  GPSS/H  uses  streams  of 
random  nurrfoers  extracted  from  a  built-in  random  number  generator.  These 
random  numbers  are  used  to  compute  the  variables  and  parameters  defined 
by  the  operands  following  GPSS/H  block  statements  (Banks  and  others, 
1989:242-244). 

Unless  the  modeler  specifies  the  random  number  stream  being  used 
by  each  stochastic  activity,  GPSS/H  uses  random  nunber  stream  (RNS)  1  as 
the  default  RNS.  By  specifying  the  random  nurber  streams  to  be  used,  or 
the  point  at  which  the  generator  selects  the  random  nunber  in  the 
stream,  the  modeler  can  control  the  variability  between  two  rur.s  or  two 
models.  For  example,  two  runs  of  an  identical  GPSS/H  model  will  produce 
identical  results  in  terms  of  number  of  transactioxis  generated,  the 
interval  between  transactions,  queue  sizes  formed,  etc.  This  occurs 
because  GPSS/H  draws  random  nurbers  from  the  same  stream  at  the  same 
point  for  corresponding  transactions  generated  by  each  run.  Variability 
between  successive  runs  must  be  accomplished  either  by  changing  the  RNS 
for  at  least  one  stochastic  activity  or  changing  the  point  in  the  RNS 
from  which  the  activity  draws  random  numbers  (Schriber,  1991:344-345). 

Changing  the  random  number  streams  of  stochastic  activities 
(blocks)  from  one  run  to  the  next  will  produce  different  results.  When 
the  "A"  (first)  operand  of  one  of  these  activities  specifies  the  type  of 
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distribution  being  used,  the  random  number  stream  being  used  is  also 
specified.  For  example,  the  GENERATE  block  followed  by  the  operand 
RVEXPO(2,10)  introduces  transactions  according  to  an  exponential 
distribution  with  a  mean  of  10.  RNS  2  is  specified  by  the  first  nurmber 
within  parentheses.  By  changing  this  nutriber  within  the  operand,  the 
random  number  stream  used  by  the  GEIIE31ATE  block  to  corrpute  the 
exponential  deviation  from  the  mean  10  is  also  changed.  Therefore,  the 
interval  between  transactions  will  be  changed  as  well  (Bamks  and  others, 
1989:249). 

Another  means  of  facilitating  variation  between  successive  runs  of 
a  single  model  is  by  changing  the  starting  point  for  the  RNS. 

Ordinarily,  the  number  sequence  for  RNS  i  is  100,000  *  i.  In  other 
words,  the  default  starting  element  of  RNS  1  is  the  100,000th  element  of 
the  sequence  produced  by  the  random  number  generator.  The  default 
starting  element  for  RNS  2  is  the  200,00th  element,  etc.  Through  the 
use  of  the  RMULT  control  statement,  this  starting  element  can  be  changed 
for  each  successive  run.  For  example,  the  block 
RMULT  299,000+1000*81 

indicates  that  the  starting  element  for  RNS  3  will  be  300,000  for  the 
first  run,  301,000  for  the  second  run,  302,000  for  the  third  run,  etc. 
(&I  is  an  ampervariable  equal  to  1  whose  value  is  incremented  by  1  with 
each  repetition  of  the  model).  Therefore,  each  stochastically- 
controlled  GPSS/H  block  statement  will  return  a  different  value  for 
corresponding  transactions  of  successive  runs  (Banks  and  others, 
1989:244-245). 

The  use  of  specified  random  number  streams  and  random  number 
stream  starting  elemer;.s  (offsets)  is  extremely  important  in  order  to 
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accurately  conpare  the  results  of  the  two  carpeting  models.  The 
objective  in  executing  the  models  is  to  determine  how  the  differences  in 
intransit  tinres  affect  model  performance,  with  all  other  model 
characteristics  beirig  equal.  The  two  models  being  compared  are 
identical ,  except  the  advance  times  representing  intransit  tines  between 
processing  points  have  been  reduced  to  zero  for  the  second  model 
(simulating  the  virtually  instantaneous  transfer  of  601  information  via 
EDI ) .  To  ensure  that  corresponding  transactions  produce  the  same 
stochastic  reactions  from  both  models,  the  random  nunt^r  streams  for 
corresponding  block  statements  are  the  same.  For  instance,  the  GENERATE 
statement  will  produce  the  same  interarrival  time  for  the  first 
tran.. action  generated  by  both  models.  The  second  transaction  produced 
will  have  a  different  interarrival  time;  however  that  time  will  still  be 
equal  for  both  models.  ADVANCE  statements  representing  601  processing 
times  and  FUNCTICS^  statements  representing  disapproval  percentages  will 
be  similarly  controlled,  resulting  in  a  mirror-image  flow  between 
corresponding  transactions  produced  in  the  same  run  of  the  two  models. 

The  random  number  streams  used  within  the  models  have  also  been 
specified  such  that  no  two  stochastically-controlled  statements  draw 
fron  the  same  random  number  stream.  The  first  variable  statement  uses 
RNS  2  (use  of  RNS  1  was  avoided  to  prevent  conflict  with  non-specified 
varicible  statements  whose  RNS  default  would  be  RNS  1),  the  second  uses 
RNS  3,  etc.  This  staggering  ensures  that  each  variable  step  is 
corpletely  independent  in  terms  of  the  random  numbers  that  control  its 
variation. 

Finally,  an  RMULT  control  statement  is  included  which  ensures  that 
the  RNS  starting  elements  differ  for  each  successive  run.  This  will 
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ensure  the  processing  and  interarrival  times,  ais  well  as  the  disapproval 
percentages  are  different  for  each  run  yet  still  the  same  for  both 
models.  As  in  the  exanple  shown  earlier,  this  is  acconplished  through 
the  inclusion  of  an  RMULT  control  stateinent  which  specifies  a  different 
RNS  starting  element  for  each  successive  run. 

The  combination  of  specified  random  number  streams  and  offsets 
ensures  that  the  two  models  are  identical  in  all  respects  except  the 
intransit  time  between  processing  points.  Any  differences  between  the 
two  TTodels'  601  residence  times  should  therefore  be  entirely  due  to  the 
difference  in  intransit  times  (the  characteristic  being  changed  by  EDI), 
and  not  by  variations  in  other  model  activities. 

Another  important  aspect  of  model  planning  was  statistical 
effectiveness.  Two  considerations  had  to  be  taken  into  account  to 
ensure  that  the  output  from  the  two  models  wais  statistically  accurate. 
One  was  sanple  size  and  the  other  was  initialization  bias.  The  first 
consideration  was  to  ensure  that  enough  601  residence  time  samples  could 
be  obtained  so  that  statistical  tests  could  be  performed  on  them.  The 
second  consideration  was  to  ensure  that  the  residence  times  reflected 
the  steady-state  cneration  of  the  system,  and  did  not  include  samples 
from  the  low-biased  initial  stages  of  the  run. 

In  order  to  get  a  sufficient  nvtnber  of  samples,  both  models  were 
set  up  to  simulate  two  years  of  system  operation.  This  was  necessary 
not  only  to  get  a  sufficient  nurfcer  of  samples  per  run,  but  also  to 
exclude  the  possibility  that  the  residence  t.me  of  any  single 
transaction  might  exceed  the  planned  run  timie.  The  number  of  samples 
returned  for  each  replication  of  the  run  will  vary  due  to  the  variations 
in  random  number  stream  offsets  that  will  change  processing  times  for 
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successive  runs.  Similarly,  the  number  of  transactions  returned  for  the 
two  models  should  differ  for  the  same  run  due  to  the  shortened  intransit 
times  inherent  in  the  second  (EDI)  model. 

A  final  consideration  in  model  planning  was  the  format  for  the 
output  data.  As  mentioned  earlier,  the  PUTFIC  statement  in  the  model 
permits  the  data  to  be  output  to  a  separate  file.  It  also  allows  the 
'jse  of  GPSS/H  staridard  nunerical  attributes  to  identify  and  collect  the 
statistics  of  interest  —  in  this  case,  the  residence  time  for  each  601 
moving  through  the  system. 

Four  different  output  files  were  specified  for  the  two  models  —  a 
file  for  both  approved  and  disapproved  601  residence  times  for  each 
model .  Because  the  residence  times  of  approved  601s  are  the  primary 
focus  of  the  study,  separate  files  for  approved  and  disapproved  601 
residence  times  were  specified  so  that  the  data  for  approved  601s  could 
be  segregated. 

Code  Description.  Once  the  flow  of  the  process  was  defined,  the 
data  to  provide  variables  and  parameters  obtained,  and  the  model 
developed  to  produce  the  desired  output,  the  GPSS/H  code  was  finalized 
(see  Appendix  C) .  Following  the  mandatory  SIMULATE  statement  in  line  1, 
the  first  step  was  to  define  the  ampervariables  that  would  later  be  used 
to  control  the  number  of  replications  and  differentiate  between  the 
initialization  run  and  the  subsequent  run  for  effect.  This  statement  in 
line  5  (the  numbers  in  the  left  margin  were  added  for  reference  purposes 
and  are  not  part  of  the  original  code) 

INTEGER  &I,S.J 

indicates  that  the  values  of  the  ampervariable  will  be  whole,  and  not 
fractional  or  decimal  numbers. 
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Following  the  anpervariable  declaration  is  the  decl" ration  of  the 
FUNCTIONS  to  be  used  in  routing  transactions.  In  lines  9  and  10,  the 
statement 

MAJ  FJNCTICX^  RN4,D2 
0.05,1/1.0,2 

specifies  the  distribution  of  trcinsactions  which  will  be  assigned  a 
parameter  value  of  1  or  2.  The  operand  RN4  specifies  the  randan  number 
stream  which  will  be  used  to  control  the  distribution  of  transactions, 
and  D2  identifies  the  FUNCTION  as  a  discrete  function  with  two  ordered 
pairs.  This  particular  FUNCTION  represents  the  disapproval  rate  for 
601s  at  the'MAJCQM  level  (five  percent),  and  will  be  used  later  to 
determine  transaction  routing.  Other  FUNCTiCX^s  identified  in  the 
declaration  include  AFLC  (line  12),  APPR  (line  15),  and  CASC  (line  18) 
which  represent  the  percentage  of  601s  disapproved  at  WR-ALC,  the 
percentage  coordinated  with  the  Item  Manager,  and  the  percentage 
coordinated  with  CASC,  respectively. 

Following  the  declaration  of  FUNCTIWs  which  determine  routing 
percentages  begins  the  block  statements  which  represent  the  actual  flow 
of  601s  through  the  system.  The  first  —  and  possibly  most  irrportant  — 
statement  controls  the  interarrival  time  of  601s.  The  block 
GSr^ERATE  RVFXPO(2,12) 

simulates  a  601  being  submitted  according  to  an  exponential  interarrival 
time  with  a  mean  of  12  days,  with  the  probability  being  calculated 
according  to  a  random  number  from  HNS  2.  This  activity  represents  the 
submission  of  601s  at  the  beise  level. 

Following  submission,  the  601  is  mailed  to  the  MAJCCM  CEI40.  The 
combination  in  blocks  24  through  27 
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ADVANCE  4 

QUEUE  MAJOR 

SEIZE  CEMO 

DEPART  MAJOR 

represents  a  four-day  irailing  time  to  the  CEMO,  and  then  arrival  at  the 
CEMO.  QUEUE  and  DEPART  statements  are  also  used  to  facilitate  queue 
mecisurement .  The  CEMO  must  then  process  the  601,  a  time  which  is 
simulated  with  the  block  statement 
ADVANCE  RVEXPO( 3,10) 

This  combination  denotes  an  exponentially-distributed  processing  time 
with  a  mean  of  10  days,  calculated  frcm  RNS  3. 

Following  processing  by  the  CEMO,  the  601  is  REILEASEd  (line  29). 
Its  fate  is  then  determined  by  the  TEST  statement  in  line  30.  The 
statement 

TESTE  FN(MAJ),2,OUT 

is  read,  "test  the  function  labeled  MAJ.  If  its  value  is  equal  to  2, 
the  transaction  goes  to  the  sijbsequent  block;  otherwise,  it  is  routed  to 
the  block  labeled  OUT."  Recall  that  in  the  FUNCTION  statement  labeled 
MAJ,  five  percent  of  the  transactions  will  be  assigned  a  value  of  1. 

The  rest  will  be  assigned  a  value  of  2.  The  TEST  statement  routes  that 
five  percent  to  the  block  labeled  COT,  an  action  which  simulates  the 
five  percent  MAJOQM  disapproval  rate.  The  remaining  601s  go  on  for 
further  evaluation. 

601s  which  are  approved  at  the  MAJCCM  level  are  routed  via  the 
ADVANCE  4  block  to  WR-ALC  (line  31).  There  they  SEIZE  the  person 
responsible  for  processing  601s.  In  line  35,  the  block 
ADVANCE  RVEXPO(5,7) 
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represents  the  processing  tine,  once  again  exponentially  distributed 
with  a  nean  of  seven  days,  and  using  RNS  5  ais  its  basis  for  calculation. 

Once  RELEASEd  fran  WR-ALC,  the  block 
TEST  E  FN(AFLC),2,0UT 

routes  601s  according  to  the  distribution  specified  in  the  FUNCTICX^ 
statenent  ladjeled  AFLC.  The  three  percent  that  are  disapproved  at  the 
WR-ALC  level  have  been  assigned  a  value  of  1  and  are  routed  to  the  block 
labeled  OUT;  the  rest  go  for  further  coordination. 

Another  TEST  statement  at  line  39  routes  four  percent  of  the 
approved  601s  to  the  Item  Manager  for  coordination  by  that  agency.  The 
block 

TEST  E  FN(APPR),1,LAST 

sends  that  small  percentage  that  require  further  coordination  to  the 
next  block.  The  rest  are  routed  to  the  block  labeled  LAST  r  represent 
601s  which  require  no  further  coordination. 

Line  40  begins  a  coordination  process  including  the  IM  and 
possibly  CASC.  The  ADVANCE  4  statement  at  line  40  simulates  the  mail 
time  for  those  601s  going  to  the  IM.  601s  then  SEIZE  the  IM  who 
determines  t.'e  type  vehicle  necessary  to  fill  the  requirement.  This 
activity  is  represented  by  the  block 
ADVANCE  RVEXPO(8,34) 

again,  cu::  exponentially  distributed  processing  time  with  a  mean  of  34 
days.  RNS  8  was  dedicated  to  this  process  to  assure  independence  from 
other  processes. 

Of  those  601s  which  must  go  to  the  IM  for  coordination,  five 
percent  must  be  coordinated  with  CASC  to  obtadn  new  stock  nimbers.  This 
activity  is  represented  in  line  45  by  the  statement 
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TEST  E  FN(CASC),1,LAST 

which  uses  the  roNCTIOT  leibeled  CRSC  to  achieve  the  distribution  of  601s 
to  be  routed  to  CASC  for  cataloging.  Those  601s  assigned  a  value  of  1 
will  be  routed  to  CASC.  The  remainder  will  be  returned  to  WR-ALC. 

Like  other  processing  times,  CASC  processing  time  is  represented 
by  an  ADVANCE  block.  The  statement 
ADVANCE  RVEXPO(10,34) 

simulates  an  exponentially  distributed  processing  time  with  a  mean  of  34 
days.  This  time,  RNS  10  controls  the  probability  distribution.  Once 
cataloging  is  ccrtplete,  the  601  is  releaised  by  both  CASC  and  the  IM,  and 
the  601  is  returned  to  WR-ALC  for  final  processing. 

Thus  far,  all  of  the  601s  that  have  been  coordinated  outside  WR- 
ALC  have  been  routed  to  the  block  labeled  SKIP  (line  51).  At  this 
point,  WR-ALC  performs  final  processing  prior  to  notifying  the 
appropriate  ccrrmand.  601s  that  did  not  reqxiire  outside  coordination 
have  been  routed  to  the  block  labeled  OKED  (line  56).  These  are  the 
last  actions  performed  on  the  601. 

The  next  set  of  statements  concerns  the  format  of  the  output  data, 
which  in  this  ceise  will  be  the  residence  time  of  each  601.  The  first 
statement 

TEST  E  SJ,2,STOP 

is  a  means  of  eliminating  the  data  from  the  initialization  period  from 
the  output  report.  In  the  initialization  period,  the  ampervariable  &J 
has  a  value  of  1,  and  all  approved  601s  are  routed  to  the  block  leibeled 
STOP.  These  bypass  the  subsequent  BFUTPIC  block.  In  the  run  for 
effect,  all  approved  601s  are  routed  to  the  blocks 
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BPUTPIC  FILE=QU00K,LINES=1,&I,N(0KED),M1 
**  ***  ***_**** 

which  designate  an  output  file  cind  format  for  601  residence  time  data. 
The  BPUTPIC  (or  block  PUTPIC)  block  outputs  the  data  from  approved  601s 
to  a  file  named  QUOOK.  One  line  is  needed  to  contain  the  data  which  is 
tadten  on  each  individual  transaction.  The  aisterisks  below  are  decimal 
holding  places  for  the  three  types  of  output  that  correspond  with  the 
items  at  the  end  of  the  BPUTPIC  statement.  The  first,  &I,  is  an 
arrpervariable  which  is  incremented  with  each  replication  and  represents 
each  replication  number.  This  data  will  go  into  the  first  two 
asterisks.  N(OKED)  is  a  Standard  Numerical  Attribute  (SNA)  that 
identifies  the  number  of  transactions  that  have  entered  that  block. 

This  number  will  go  into  the  second  set  of  transactions.  Finally,  Ml  is 
another  SNA  that  measures  the  residence  times  of  transactions  moving 
through  that  block.  The  output  file  QUOOK  will  therefore  contain  the 
replication  number,  the  transaction  number,  and  the  residence  time  of 
each  601  that  is  approved.  These  transactions  are  then  routed  to  the 
TERMINATE  0  block  in  line  60  where  they  are  destroyed. 

As  601s  are  disapproved  in  the  model ,  they  have  been  routed  to  the 
block  labeled  OUT  (line  61).  Initialization  data  is  once  again  filtered 
out  of  the  output  file  through  the  use  of  the  TEST  statement  in  line  62. 
Another  BPUTPIC  file  has  been  identified  in  line  63  to  collect  output 
statistics  for  disapproved  601s,  should  they  be  examined  later.  Like 
the  approved  601s,  disapproved  601  transactions  are  destroyed  by  a 
TERMINATE  0  statement. 

Although  the  model  block  statements  represent  the  actual  601  flow, 
other  control  statements  are  needed  to  establish  the  behavior  of  the 
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model.  The  first  of  these  is  the  GENERATE  730  statement  at  line  69. 

When  730  days  have  elapsed,  this  statemKit  introduces  a  transaction  that 
enters  the  subsequent  block,  TERMINATL  1,  and  stops  the  run.  Therefore, 
the  duration  of  each  run  of  the  model  is  730  days. 

Other  run  control  statements  also  determine  the  behavior  of  the 
model.  At  line  74,  the  block 
DO  &I=1,10,1 

performs  a  repeated  loop  of  the  ccmnands  that  follow.  The  operand  &I, 
an  integer  airpervariable,  is  incremented  by  1  for  each  replication. 

When  its  value  equals  the  value  of  the  second  operand,  10,  the  DO-loop 
is  terminated.  The  final  operand  tells  the  model  to  increase  the  value 
of  the  first  operand  in  increments  of  1. 

The  LET  &J=1  statement  at  block  75  assigns  a  value  of  1  to  the 
anpervariable  &J.  Although  not  crucial  to  the  model  flow,  this  value  is 
used  in  the  TEST  statement  in  blocks  57  and  62  to  exclude  initialization 
data  from  the  output  files.  This  will  simplify  evalixation  of  the  output 
data. 

Another  block  that  does  not  influence  the  model  flow,  but  does 
control  the  variances  in  processing  times  and  routing  fron  run  to  run  is 
the  RMULT  block  in  lines  76  through  84.  This  block  performs  a 
computation  which  defines  a  new  starting  point  for  F?NS  2-10,  a  starting 
point  which  changes  with  each  incrementation  of  SI.  Therefore,  each  RNS 
has  a  new  offset  for  each  run  in  order  to  vary  the  output  from 
stochcistically-controlled  corrmands  in  the  block  statements.  In  other 
words,  each  step  in  the  process  will  return  a  different  value  from  run 
to  run. 
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Once  the  model  hcis  compiled  the  instructions  contained  in  the 
code,  the  START  1,NP  command  in  line  85  executes  the  model.  In  this 
case,  it  runs  the  model  for  one  730  day  period,  but  does  not  print  the 
results  to  a  model  file  (to  prevent  the  model  from  using  disk  space  for 
unneeded  data).  Following  this  initialization  run,  the  RESET  statement 
resets  all  statistics  to  zero,  but  does  not  remove  the  current 
transactions  from  the  model.  In  this  manner,  model  statistics  are 
recorded  beginning  at  a  point  in  which  the  process  has  reached  steady 
state. 

For  the  second  run,  the  value  of  &J  is  changed  to  2  (line  87). 

This  anpervaria^Dle  is  used  in  the  TEST  statements  in  lines  57  and  62  to 
route  transactions  through  the  BPUTPIC  blocks  so  that  data  can  be 
recorded  for  the  run  for  effect.  Again,  the  model  is  STARTed  and  run. 
Following  each  run  for  effect,  the  CLEAR  statement  in  line  89  clears  all 
transactions  from  the  model  and  zeroes  out  all  statistics. 

The  model  continues  this  process  for  ten  replications.  Because 
cost  and  computer  time  were  not  a  consideration  given  the  language  used 
and  the  size  of  the  model,  ten  replications  will  provide  more  than  a 
sufficient  number  of  individual  601  sanples  for  statistical 
significance,  and  will  also  facilitate  additional  variation  in  activity 
times.  The  EITODO  statement  at  line  90  increments  &I,  and  begins  a  new 
iteration  of  the  DOloop,  until  the  first  aivd  second  operands  of  the  DO 
statement  are  equal.  After  this  run,  the  EITODO  statement  is  bypassed, 
the  Eiro  statement  is  encountered,  and  model  execution  is  terminated. 

As  mentioned  previously,  the  second  model  —  the  one  which 
simulates  the  601  process  with  the  integration  of  EDI  --  is  identical  to 
the  first  with  the  exception  of  the  blocks  which  represent  intransit 
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times  between  processing  points  (see  Appendix  D).  For  the  second  model 
the  times  for  these  ADVANCE  blocks  have  been  reduced  to  zero  to  simulate 
the  virtually  instantaneoxis  transmittal  of  the  information  contadned  on 
the  form  601. 

Summary 

This  chapter  has  outlined  some  of  the  concepts  of  the  GPSS/H 
simulation  language,  and  has  explained  seme  of  the  considerations  used 
in  model  development  including  variability,  syncronization,  and 
statistical  significance.  The  chapter  also  explained  the  application  of 
GPSS/H  simulation  code  to  each  step  of  the  601  process,  as  well  as  other 
features  which  permit  data  collection  and  multiple  executions  of  each 
model . 

The  completion  of  the  model  code,  the  culmination  of  the  model 
formulation  process,  leads  to  the  next  phase,  experimentation.  In  this 
phase  the  two  models  will  be  run,  the  output  compared,  and  conclusions 
formed.  Additionally,  the  output  will  be  evaluated  to  identify  system 
behavior  such  as  bottlenecks,  flow  rates,  etc.  to  determine  the  effects 
of  EDI  on  statistics  other  than  residence  times. 
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V.  Experimentation  and  Conclusions 


Introduction 

Following  developnrent  of  the  two  GPSS/H  models,  the  next  step  is 
to  execute  the  models  to  examine  differences  in  601  residence  times,  as 
well  as  other  differences  that  become  apparent  through  experimentation. 
Corparison  will  consist  of  compiling  the  residence  time  data  in  an 
output  file,  determining  differences  in  average  residence  times  for  each 
model  replication,  and  determining  confidence  intervals  for  those 
average  differences.  Experimentation  may  also  reveal  unanticipated 
behavior  resulting  from  the  inclusion  of  EDI  into  the  process.  Further 
model  modification  may  be  necessary  in  order  to  characterize  and 
quantify  that  behavior. 

Output  Comparison 

Output  comparison  will  first  involve  determining  the  average  601 
residence  time  for  each  run.  Using  the  paired- t  test  described  by 
Schriber,  average  601  residence  times  for  each  run  of  the  model 
representing  the  system  with  EDI  included  will  be  rratched  with  the  ten 
averages  of  corresponding  runs  of  the  base  model.  Differences  will  be 
taken  between  the  matched  pairs,  and  confidence  intervals  obtained  for 
the  average  differences.  The  result  will  provide  a  reliable  measure  of 
the  actual  time  savings  independent  of  other  uncontrol laddie  factors  such 
as  process  times  and  transaction  routing. 
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Model  Execution 


In  order  to  errploy  the  paired- 1  test,  the  model  was  run,  and  the 
resulting  residence  times  for  approved  601s  were  output  to  two  files  — 
QJOOK  contedning  residence  times  for  the  status  quo  system  and  EDICK 
containing  residence  times  for  the  system  simulating  EDI  integration. 
These  ASCII  files  were  inported  into  a  spreadsheet  program  to  facilitate 
operations  associated  with  the  paired-t  test.  Average  system  residence 
times  were  taken  for  each  of  the  ten  replications  of  both  models.  The 
average  of  the  first  replication  for  the  baise  (without  EDI)  model  was 
paired  with  the  average  for  the  first  replication  of  the  experimental 
(with  EDI)  model.  This  was  done  for  the  remaining  nine  replications  as 
well.  Table  1  displays  the  results  of  the  experiment. 

Confidence  Intervals  for  Model  Experimentation 

The  differences  in  paired  averages  of  the  model  using  mail  as  the 
primary  source  of  transmitting  601s  and  the  model  incorporating  EDI  were 
recorded  and  confidence  intervals  were  obtained  for  the  mean  of  those 
differences.  The  confidence  intervals  were  calculated  according  to  the 
formula  annotated  in  Eq  (1)  in  chapter  3. 

The  mean  difference  in  the  residence  times  was  approximately  nine 
days,  a  processing  time  iirprovement  of  adxjut  ten  percent.  A  90  percent 
confidence  interval  calculation  revealed  a  mean  residence  time 
difference  of  between  8.31  and  9.81  days.  A  95  percent  confidence 
interval  was  calculated  with  a  mean  residence  time  difference  of  between 
8.07  and  10.05  days.  Because  the  confidence  interval  did  not  span  zero, 
the  inclusion  of  EDI  can  be  interpreted  as  having  iirproved  system 
residence  times  as  measured  by  this  experiment.  Thus,  the  mean 
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TABLE  1 


601  RESIDENCE  TIMES 


REP  # 

CURRENT 

SYSTEM 

SYSTEM 

W/EDI 

DIFFERENCE 

1 

81.46149 

75.0052 

6.456291 

2 

38.69103 

30.5525 

8.138532 

3 

199.8258 

188.9785 

10.84731 

4 

190.0858 

181.9644 

8.121457 

5 

50.7014 

43.2427 

7.458706 

6 

93.13842 

83.4275 

9.710913 

7 

73.83199 

65.22892 

8.60307 

8 

69.07305 

58.69518 

10.37787 

9 

105.3278 

93.17144 

12.15634 

10 

46.99104 

38.27762 

8.713423 

MEAN: 

94.91278 

85.85439 

9.058391 

STD  DEV: 

56.64835 

56.12435 

1.7108982 

OCOT'IDENCE  INTERVALS 
FOR  MEAN  DIFFERENCE: 

LOWER  UPPER 

90%  Cl:  8.310142  9.806641 

95%  Cl:  8.066677  10.05011 


improverrent  in  residence  times  can  be  predicted  with  95  percent 
probability  as  being  between  eight  and  ten  days  for  this  experiment. 

These  results  fail  to  reject  the  original  hypothesis  that  the 
inclusion  of  EDI  will  iirprove  (reduce)  overall  601  residence  times. 

With  all  uncontrol  laddie  factors  accounted  for,  the  integration  of  an 
instantaneous  transmittal  of  information  via  EDI  appears  to  reduce  the 
average  601  residence  tim"  by  approximately  nine  days  over  an  identical 
system  using  mail  as  the  primary  means  of  transmittal .  An  important 
note,  however,  is  that  the  models  evaluate  only  the  effects  of  faster 
transmittal  inherent  with  EDI  —  no  other  benefits  such  eis  iirproved 
accuracy  or  reduced  processing  time  were  incorporated  into  this 
experiment . 
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Varietbilitv 


Another  important  finding  was  that  the  time  savings  apparently 
resulting  from  EDI  remained  relatively  fixed  over  the  entire  range  of 
601  residence  times.  While  the  standard  deviation  for  time  savings  was 
only  1.72  days,  the  standard  deviation  for  residence  times  for  the 
experimental  (including  EDI)  model  was  56.12  days.  Time  savings  do  not 
increase  proportionally  with  increases  in  residence  times  resulting  from 
stochastic  variation  in  processing  tines  and  routing.  In  other  words, 
the  time  savings  do  not  vary  much  whether  the  entire  residence  time  was 
20  days  or  100  days.  Thus,  it  appears  that  reductions  in  intransit 
times  do  not  result  in  a  synergy  that  reduces  the  time  spent  at  each 
processing  point. 

Impact  of  EDI  on  Queue  Length 

Intuitively,  improved  intransit  times  should  improve  system 
throughput  and  therefore  reduce  overall  residence  times.  Although 
instantaneous  transmittal  does  appear  to  reduce  overall  residence  times 
by  six  to  twelve  days,  processing  points  do  not  appear  able  to  exploit 
the  intransit  time  advantages  provided  by  EDI,  thus  providing  time 
savings  over  and  above  the  savings  in  intransit  times  alone.  One 
possible  explanation  for  this  counterintuitive  behavior  is  that 
improvements  in  transmittal  time  are  offset  by  increased  queue  sizes 
that  accunulate  at  each  processing  point.  In  other  words,  although  EDI 
does  speed  transmittal  time,  processing  points  do  not  process  faster  (at 
leeist  given  the  assumptions  of  this  model)  and  601s  which  arrived  more 
quickly  end  up  waiting  anyway. 
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To  examine  this  effect  more  closely,  both  models  were  modified  to 
incorporate  an  additional  PUTPIC  statement  into  the  control  statements 
at  the  end  of  the  models.  This  statement,  inserted  after  the  START  1 
statement  in  block  89,  took  the  form 
PUTPIC  FILE=QSIZE,LINES=l,SI,0A(MAJOR),gM(MAJOR)  ,QA(ALC) ,_ 

QM(ALC) 

where  QA(MAJCi<)  is  a  Standard  Numerical  Attribute  (SNA)  that  records  the 
average  contents  of  a  queue  named  MAJOR,  QH(MAJOR)  is  an  SNA  that 
records  the  maximum  contents  of  the  queue  named  MAJOR,  OA(ALC)  records 
the  average  contents  of  the  queue  ALC,  and  QM(ALC)  records  the  maximum 
contents  of  the  queue  ALC. 

Both  models  were  run  once  more,  with  the  output  of  the  new 
experiment  going  to  a  file  named  QSIZE  for  the  base  model  and  EDISIZE 
for  the  experimental  model.  Once  again  the  ASCII  files  were  imported  to 
a  spreadsheet  to  facilitate  mathematical  conrparison;  however,  the  queue 
statistics  for  both  models  were  found  to  be  identical.  Surprisingly, 
queue  sizes  and  maxirrun  queue  lengths  did  not  vary  despite  the  faister 
transmittal  time  offered  by  EDI. 

Average  queue  sizes,  however,  did  reveal  some  interesting  data. 
Although  the  queue  sizes  for  the  base  model  MAJCOM  facility  were 
expected  to  be  shorter  overall  due  to  the  buffering  effect  of  the  longer 
treUismittal  time,  this  was  not  the  case.  The  continuous  presence  of  at 
least  one  601  in  the  queue  seems  to  negate  this  buffering  effect  and 
perpetuates  the  same  queuing  behavior  as  the  model  with  EDI.  Again, 
Forrester’s  counterintuitive  behavior  attribute  of  systems  became 
apparent.  Average  queue  sizes  for  the  MAJCCM  processing  point  ranged 
from  one  to  fifteen  601s  for  both  models.  Although  this  phenomena  was 
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less  apparent  for  the  facility  ROBINS,  a  faster  processing  time  at  this 
facility  would  probably  account  for  the  smaller  queue  sizes.  This  data 
also  points  to  the  MAJCCM  as  the  system's  primary  constraint  point. 

Not  surprisingly,  replications  characterized  by  longer  average 
residence  times  also  had  longer  average  queue  lengths.  The  first-in, 
first-out  processing  system  results  in  dependent  residence  times  among 
sequential  transactions.  In  other  words,  if  a  transaction  experiences 
an  abnormal ly- long  residence  time,  the  next  transaction  will  probably 
have  to  wait  in  queue  and  will  therefore  suffer  a  similarly- long 
residence  time.  This  effect  can  also  be  seeii  in  the  raw  residence  time 
data  (see  Appendix  E  cind  F).  One  long  residence  time  seems  to  spawn  a 
string  of  longer  residence  times.  Short  residence  times  likewise  appear 
to  perpetuate  strings  of  shorter  processing  times.  Forrester  noted  this 
interdependent  behavior  as  an  attribute  of  some  systems. 

How  significant  is  the  MAJCCM  processing  time  to  the  overall 
residence  time  of  601s?  To  compare  the  relative  effects  of  processing 
times  versus  faster  transmittal  times,  a  peiired-t  test  was  performed 
between  the  base  model  and  one  in  which  the  MAJCCM  mean  processing  time 
was  reduced  from  ten  to  seven  days.  The  average  residence  tir>es  for 
each  replication  were  paired  and  differences  obtained.  Table  2  displays 
the  results. 

While  the  average  difference  between  the  base  model  and  the  EDI- 
incorporated  model  was  approximately  nine  days,  the  difference  between 
the  base  model  and  one  incorporating  a  shorter  MAJCCM  processing  time 
was  an  average  of  52  days.  This  equates  to  a  54  percent  improvement  in 
residence  times.  Confidence  intervals  for  the  mean  difference  spanned 
from  30.48  to  74.91  at  the  ,90  level  of  significance  to  23.25  to  82.14 
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TABLE  2 


AVERAGE  601  RESIDENCE  TIMES  - 
REDUCED  MAJCCM  PROCESSING  TIME 


CURRENT 

MAJCCM 

MAJCCM 

TIME 

REP  # 

TIME 

REDUCED 

DIFFERENCE 

1 

73.19944 

46.89783 

26.30161 

2 

128.1276 

27.2437 

100.8839 

3 

207.1168 

45.21561 

161.9012 

4 

115.2391 

37.35338 

77.88574 

5 

87.25546 

43.2427 

44.01276 

6 

77.21047 

50.27331 

26.93716 

7 

76.68494 

46.22276 

30.46219 

8 

100.8262 

36.04825 

64.77796 

9 

61.3832 

68.562 

-7.1788 

10 

30.00082 

29.04116 

0.959659 

MEAN: 

95.70441 

43.01007 

52.69434 

STD  DEV: 

47.89845 

11.83302 

50.7936 

CONFIDENCE  INTERVALS 
FOR  MEAN  DIFFERENCE 

LOWER  UPPER 

90%  Cl:  30.48011  74.90856 

95%  Cl:  23.25206  82.13662 


at  the  .95  level  of  significance.  Again,  the  confidence  interval  did 
not  span  zero  and  the  results  indicate  with  95  percent  probability  that 
the  actual  mean  time  savings  for  the  experiment  is  between  23  and  82 
days.  Given  the  reductions  in  process  times  noted  by  such  ccrtpanies  cls 
Conrail  and  Interamerican  Transport  Systems  (Chapter  2),  process  time 
reductions  and  time  savings  such  as  these  would  not  be  unexpected. 

This  finding  is  iirportant  because  it  indicates  that  overall 
residence  times  can  probably  be  inproved  more  through  reductions  in 
processing  times  than  through  inprovements  in  transmittal  flow  rates,  at 
least  given  the  current  variables  and  parameters  in  the  model.  For 
these  models,  a  three-day  reduction  in  MAJCCM  processing  time  had  a 
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greater  effect  on  residence  times  than  did  a  four-day  reduction  in 
intransit  times.  These  results  indicate  that  most  of  the  601  residence 
time  is  spent  waiting  to  be  processed,  at  least  at  the  MAJCQM  level.  As 
process  times  decresise,  transmittal  times  should  have  more  of  an  effect 
on  overall  system  residence  times. 

In  surtmary,  faster  transmittal  times  do  appear  to  have  a  positive, 
if  not  relatively  small  effect  on  overall  601  residence  times. 

Reductions  in  transmittal  times  alone,  however,  will  continue  to  produce 
only  nBrginal  irnprovements  in  residence  times  until  processing  times  can 
be  reduced  as  well.  The  overall  governor  of  system  residence  times  will 
be  the  activity  with  the  longest  duration  —  in  this  caise,  the  MAJCQM 
processing  time.  As  noted  earlier,  some  inprovements  in  processing 
times  may  result  from  other  benefits  of  EDI  —  more  accuracy,  fewer 
keystrokes,  and  better  database  utilization.  Making  more  conclusive 
evaluations  of  the  effects  of  shorter  processing  times  will  reqiiire  a 
more  in-depth  study  of  the  actual  mechanics  of  601  processing  at  each 
point,  as  well  cis  a  standardized  EDI  format  on  which  to  beise 
iirprovements  in  those  processing  mechanics. 

Findings 

The  data  obtained  from  the  execution  of  the  GPSS/K  model  supports 
the  hypothesis  that  the  faster  transmittal  time  made  possible  through 
the  integration  of  EDI  into  the  601  process  reduces  the  overall 
residence  times  of  601s  in  the  system.  By  reducing  transmittal  times 
from  four  days  to  zero,  an  average  of  nine  days  can  be  reduced  from  the 
average  601  system  residence  time.  The  data  also  suggests  that 
inprovements  in  601  residence  times  will  be  limited  by  processing  times 
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at  the  MAJOCM  and  other  activity  centers.  More  substantial  reductions 
in  residence  times  will  occur  when  MAJCCM  and  other  activity  processing 
times  can  be  reduced  so  that  they  can  exploit  the  faister  transmittal 
times  inherent  in  EDI.  In  fact,  reductions  in  processing  times  at  the 
MAJCOM  appear  to  have  a  far  greater  effect  on  system  residence  times 
than  reductions  in  transmittal  times. 

Although  not  studied  in  this  research,  the  incorporation  of  an 
integrated  EDI  system  such  as  AFEMS  will  certainly  offer  reductions  in 
transmittal  times,  and  may  offer  substantial  reductions  in  processing 
time  through  improved  accuracy,  reduced  research  requirements,  and 
better  database  utilization  and  management.  This  would  acccmplish  the 
goal  of  developing  a  601  process  that  is  more  responsive  to  managers  at 
all  levels. 

Suggestions  for  Further  Research 

Although  the  research  explored  seme  useful  methods  for  evaluating 
the  effects  of  EDI,  and  resulted  in  some  useful  information  about  the 
behavior  of  the  601  process,  some  further  research  should  be 
accomplished  to  expand  the  effectiveness  of  this  methodology  as  a  means 
of  EDI  evaluation.  First,  the  model  should  be  modified  to  incorporate 
actual  variable  and  parameter  data  from  a  limited  number  of  bases  under 
a  single  MAJCCM.  Actual  data  would  allow  firm  eissessments  to  be  made 
concerning  data  distribution  and  other  characteristics  that  would 
possibly  make  the  model  a  more  accurate  representation  of  the  actual 
system.  Although  gathering  enough  data  to  make  the  model  representative 
of  all  USAF  bases  would  be  extremely  difficult  if  not  impossible, 
limiting  data  to  actual  historical  data  frem  a  few  bases  and  a  single 
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MAJCXDM  could  allow  the  modeler  to  make  scientific  judgements  about  the 
effects  of  EDI  at  those  bases. 

To  acccrrplish  this  task,  the  researcher  should  establish  and 
maintain  a  log  of  actual  601  varieibles  and  parameters  as  observed  over 
the  course  of  several  months.  The  log  should  include  the  same  variables 
cuid  parameters  that  were  estimated  for  this  model  —  processing  times, 
interarrival  times,  and  intransit  times. 

As  mentioned  previously,  another  key  focus  of  future  research 
should  be  potential  for  reductions  in  processing  times.  Because 
processing  times  appear  to  hold  the  most  premise  for  reducing  overall 
601  residence  times,  they  should  be  researched  carefully  to  determine 
the  extent  to  which  they  might  offer  savings,  both  in  time  and  money. 
Such  research  will  require  an  in-depth  analysis  of  the  mechanics  of  601 
processing.  Current  processing  methods  must  be  compared  with  those 
accomplished  using  a  standardized  EDI  format  such  as  AFEMS.  Comparisons 
could  use  the  same  methodology  established  in  this  research,  and 
combined  with  expected  reductions  in  intransit  times,  result  in  a  total 
benefit  package  for  EDI. 

This  research  has  barel;  touched  the  surface  of  the  capabilities 
of  computer  simulation  as  a  tool  for  measuring  the  effects  of  EDI  on 
this  and  other  coor^'ination  processes,  particularly  if  processing  time 
reductions  are  evaluated  and  quantified.  For  example,  AFEMS  features 
could  be  evaluated  to  obtain  not  only  the  degree  of  time  savings 
resulting  from  AFEMS,  but  labor  cost  savings  as  well. 

The  model  could  also  be  used  to  perform  cost/benefit  analysis  for 
the  various  features  of  AFEMS  or  other  EDI  formats.  Some  features 
obviously  cost  more  than  others  to  develop  and  deploy.  By  using  the 
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model  as  a  tool  to  determine  which  features  result  in  the  most  efficient 


program  management,  program  developers  could  avoid  the  costs  of 
inpleiienting  "gold  plated"  features  which  offer  little  in  the  way  of 
benefit. 

Finally,  the  model  could  be  used  to  determine  if  AFEMS  will  offer 
sufficient  overall  manpower  savings  to  offset  its  development  and 
inplementation  costs.  System  maintenance  and  other  factors  should  also 
be  evaluated  to  weigh  the  tradeoffs  between  system  costs  and  meinpower 
savings  and  effectiveness. 

Overall,  the  irrplementation  of  EDI  as  a  means  of  transmitting 
critical  vehicle  data  appears  to  offer  significant  benefits, 
particularly  if  the  program  incorporates  features  which  reduce  not  only 
transmittal  time  but  processing  time  as  well.  The  true  meaisure  of 
success  will  be  not  only  the  degree  to  which  EDI  reduces  601  turnaround 
time,  but  the  degree  to  which  it  adds  value  to  the  managers  who  depend 
on  the  process  at  all  levels. 
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endix  B:  Model  Variables  and  Parameters 

A.  Base-level  inputs.  Inputs  for  model  variables  and 
parameters  were  obtained  through  structured  telephone 
interviews  with  fleet  managers  at  the  respective  bases. 
Questions  and  responses  are  noted  below: 

1.  How  often  are  601s  submitted? 

EGLIN:  80  per  year  EDWARDS:  60  per  year 

WHITEMAN:  12  per  year  LORING:  12  per  year 

MOODY:  36  per  year  MACDILL:  15  per  year 

TRAVIS:  18  per  year  DOVER:  16  per  year 

AVG:  249  per  year  or  1  every  11.73  days.  Rounded  up  to  12, 

this  figure  becomes  the  average  interarrival  time  for  601s 

in  the  model . 

2.  What  is  the  intransit  time  to  the  servicing  MAJCOM? 
EGLIN:  4  days  EDWARDS:  5  days 

WHITEMAN:  3  days  LORING:  3  dgys 

MOODY:  4  days  MACDILL:  4  days 

TRAVIS:  4  days  DOVER:  4  days 

AVG:  3.875  days.  Rounded  up  to  4,  this  figure  becomes  the 

intransit  time  from  base  level  to  the  MAJCOM. 

B.  MAJCOM  inputs.  These  inputs  were  obtained  from  the 
CEMO  managers  at  the  respective  MAJCOMs  through  structured 
telephone  interviews. 
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1.  Approximately  what  percentage  of  the  601s  that  you 
receive  are  disapproved  due  to  administrative  errors  or 
inadequate  justification? 

AFSC:  2  percent  MAC:  4  percent 

TAG:  6  percent  SAC:  5  percent 

AVG:  4.25  percent.  Rounded  up  to  5,  this  figure  becomes 

the  disapproval  rate  at  MAJCOM. 

2.  What  is  your  average  processing  time  for  601s? 

AFSC:  5  days  MAC:  21  days 

TAC:  10  days  SAC:  2  days 

AVG:  9.5  days.  Rounded  up  to  10,  this  figure  becomes  the 

MAJCOM  processing  time. 

3.  What  is  the  approximate  intransit  time  to  WR-ALC? 

AFSC:  3  days  MAC:  4  days 

TAC:  5  days  SAC:  4  days 

AVG:  4  days.  This  figure  becomes  the  intransit  time  from 

the  MAJCOM  to  WR-ALC. 

C.  WR-ALC  1 evel .  All  model  variables  and  parameters 
for  WR-ALC  were  obtained  through  personal  and  telephone 
interviews  with  AFSED  personnel  and  are  reflected  directly 
in  the  model . 

1.  What  percentage  of  the  601s  that  you  receive  are 
disapproved  due  to  administrative  error  or  inadequate 
justification?  Answer:  3  percent.  Becomes  WR-ALC 
disapproval  percentage  for  the  model . 
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2. 


What  is  the  average  processing  time  for  601s  at  WR- 
ALC?  Answer:  7  days.  This  figure  becomes  the  WR-ALC 
processing  time  for  the  model. 

3.  What  is  the  percentage  of  60is  that  must  be 
coordinated  with  the  Item  Manager?  Answer:  4  percent. 

This  figure  becomes  the  percentage  routed  to  the  Item 
Manager  in  the  model . 

4.  What  is  the  average  601  processing  time  for  IMs? 

Answer:  34  days.  Becomes  IM  processing  time  in  the  model. 

5.  Of  those  601s  that  go  to  the  IM,  what  percentage  must 
be  coordinated  with  CASC?  Answer:  5  percent.  Becomes 
percentage  of  601s  that  are  routed  from  the  IM  to  CASC  in 
the  model . 

6.  What  is  the  average  CASC  processing  time  for  601s? 

Answer:  34  days.  Becomes  CASC  processing  time  for  the 

model . 
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Appendix  C:  Computer  Code  for  Present  601  Flow 


1  SIMULATE 

3  *  Ampervariable  Declaration 

5  INTEGER  &I,&J 

7  *  Control  Statements  (functions) 

g  ttittttttitiiiittttttttttttttttttttlitttttttttttiiitttttttttitttttttttttttttttttlttt 


9 

HAJ  FUNCTION  RN4,D2 

10 

0.05,1/1.0,2 

5  percent  disapproved  by  MAJCOM 

11 

* 

12 

AFLC  FUNCTION  RN6,D2 

13 

0.03,1/1.0,2 

3  percent  disapproved  by  HR-ALC 

14 

* 

15 

APPR  FUNCTION  RN7,D2 

16 

0.04,1/1.0,2 

4  percent  coordinated  with  IM 

17 

* 

18 

CASC  FUNCTION  RN9,D2 

19 

0.05,1/1.0,2 

5  percent  coordinated  with  CASC 

20 

21 

*  Status  Quo  601  Flow 

22 

23 

GENERATE 

RVEXPO(2,12) 

601  submitted  every  12  days  on  average 

24 

ADVANCE 

4 

Transit  time  for  601  to  MAJCOM 

25 

QUEUE 

MAJOR 

Collect  waiting  time  stats  for  CEMO 

26 

SEIZE 

CEMO 

601  Arrives  at  MAJCOM 

27 

DEPART 

MAJOR 

Calculate  waiting  time  stats  for  CEMO 

28 

ADVANCE 

RVEXPO(3,10) 

MAJCOM  processing  time  for  601 's 

29 

RELEASE 

CEMO 

MAJCOM  completes  601  processing 

30 

TEST  E 

FN(MAJ),2,OUT 

5%  of  601s  disapproved  --  go  to  OUT 

31 

ADVANCE 

4 

Transit  time  for  601  to  WR-ALC 

32 

QUEUE 

ALC 

Collect  waiting  time  stats  for  ROBINS 

33 

SEIZE 

ROBINS 

601  arrives  at  KR-ALC 

34 

DEPART 

ALC 

Calculate  waiting  time  stats  for  ROBINS 

35 

ADVANCE 

RVEXPO(5,7) 

KR-ALC  processing  time  for  601 's 

36 

RELEASE 

ROBINS 

KR-ALC  coord,  approves,  or  disapproves  601 

37 

TEST  E 

FN(AFLC) ,2,OUT  3%  of  601s  disapproved  --  go  to  OUT 

38 

ADVANCE 

0 

39 

TEST  E 

FN ( APPR ) ,1, OKED  4%  go  to  IM  for  coordination 

40 

ADVANCE 

4 

Intransit  time  to  IM 

41 

QUEUE 

ITEM 

Collect  waiting  time  stats  for  ITEMMGR 

42 

SEIZE 

ITEMMGR 

60rs  received  by  appropriate  IM 

43 

DEPART 

ITEM 

Calculate  waiting  time  stats  for  ITEM.MGR 

44 

ADVANCE 

RVEX?0(8,34) 

Item  manager  processing  time  for  601's 

45 

TEST  E 

FN( CASC ),1, SKIP  5%  coordinated  with  CASC 

46 

QUEUE 

CREEK 

Collect  waiting  time  stats  for  CASC 

47 

SEIZE 

BATTLE 

CASC  begins  processing 

48 

DEPART 

CREEK 

Calculate  waiting  time  stats  for  CASC 
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49  ADVANCE  RVEXPO(10,34)  CASC  processing  time 

50  RELEASE  BATTLE  CASC  completes  processing 

51  SKIP  RELEASE  ITEMMGR  IM  returns  601  to  WR-ALC 

52  ADVANCE  4  Transit  time  from  IM  to  WR-ALC 

53  SEIZE  ROBINS  WR-ALC  receives  601 

54  ADVANCE  3  WR-ALC  performs  final  processing 

55  RELEASE  ROBINS  WR-ALC  notifies  base  of  approved  601 

56  OKED  ADVANCE  0 

57  TEST  E  &J,2,ST0P  Do  not  record  times  for  initialization 

58  BPUTPIC  PILE:QUOOK,LINES:1,&I,N(OKED),M1 

59  **  *tt 

60  TERMINATE  0 

61  OUT  ADVANCE  0 

62  TEST  E  &J,2,STOP  Do  not  record  times  for  initialization 

63  BPUTPIC  PILE=QUOBAD,LINES=l,SI.N{OUT),Hl 

54  t*  *** 

65  STOP  TERMINATE  0 

67  *  Run-Control  Xact 

69  GENERATE  730  Simulate  730  days  (2  years)  system  operation 

70  TERMINATE  1  Terminate  run  at  end  of  2  years 

72  *  Run-Control  Statements 

73  iliittitittttttttttttttiittttttilttttiltttttitltttitmttttttttitiiittttttttiititiiit* 


74 

DO 

61=1,10,1 

Perform  10  replications 

75 

LET 

&J=1 

Assign  value  of  6J 

76 

RMULT 

,199000+1000*&I,_ 

RN2  offset  for  current  replication 

77 

299000+1000*61, _ 

RN3  offset  for  current  replication 

78 

399000+1000*61, _ 

RN4  offset  for  current  replication 

79 

499000+1000*61, _ 

RN5  offset  for  current  replication 

80 

599000+1000*6I,_ 

RN6  offset  for  current  replication 

81 

699000+1000*61, _ 

RN7  offset  for  current  replication 

82 

799000+1000*6I,_ 

RN8  offset  for  current  replication 

83 

899000+1000*61, _ 

RN9  offset  for  current  replication 

84 

999000+1000*61, 

RNIO  offset  for  current  replication 

85 

START 

1,NP 

2-year  initialization  period 

86 

RESET 

Reset  all  statistics  to  zero 

87 

LET 

6J=2 

Change  value  ot  6J 

88 

START 

1 

Run  model  for  effect 

89 

CLEAR 

Clear  stats  and  transactions  from  model 

90 

ENDDO 

Next  value  of  61 

91 

END 

92 
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Appendix  D:  Computer  Code  for  601  Flow  With  EDI 


1  SIMULATE 

3  *  Anpervariable  Declaration 

5  INTEGER  SI,&J 

7  *  Control  Statements  (functions) 


9 

MAJ  FUNCTION  RN4,D2 

10 

0.05,1/1.0,2 

5  percent  disapproved  bj  KAJCOM 

11 

* 

12 

AFLC  FUNCTION 

iJI6,D2 

13 

0.03,1/1.0,’ 

3  percent  disapproved  by  HR-ALC 

14 

t 

15 

APPR  FUNCTION  RN7,D2 

16 

0,04,1/1.0,2 

4  percent  coordinated  with  I.M 

17 

i 

18 

CASC  FUNCTION 

RN9,D2 

19 

0.05,1/1.0,2 

5  percent  coordinated  with  CASC 

20 

ttittttttttitlititiitittttttttittttttttttttttttttttitttttttttttttttttttttttttttit 

21 

*  601  Flow  With  EDI 

22 

23 

GENERATE 

RV£XPO(2,12) 

601  submitted  every  12  days  on  average 

24 

ADVANCE 

0 

Transit  time  for  601  to  MAJCOM 

25 

QUEUE 

MAJOR 

Collect  waiting  time  stats  for  CEMO 

26 

SEIZE 

CE.MO 

601  Arrives  at  MAJCOM 

27 

DEPART 

MAJOR 

Calculate  waiting  time  stats  for  CEMO 

28 

ADVANCE 

RVEX?0(3,1C) 

MAJCOM  processing  time  for  601 's 

29 

RELEASE 

CEMO 

MAJCOM  completes  601  processing 

30 

TEST  E 

FN(MAJ),2,CUT 

5%  of  601s  disapproved  --  go  to  OUT 

31 

ADVANCE 

0 

Transit  tine  for  601  to  KR-ALC 

32 

QUEUE 

ALC 

Collect  waiting  time  stats  for  ROBINS 

33 

SEIZE 

ROBINS 

601  arrives  at  HR-ALC 

34 

DEPART 

ALC 

Calculate  waiting  time  stats  for  ROBINS 

35 

ADVANCE 

RVEXPO(5,7) 

HR-ALC  processing  time  for  601 's 

36 

RELLASE 

ROBINS 

HR-ALC  coord,  approves,  or  disapproves  601 

37 

TEST  E 

FN(ArLC),2,OU' 

T  3%  of  601s  disapproved  --  go  to  OUT 

38 

ADV.ANCE 

0 

39 

TEST  E 

fn(appr),i,o.k: 

ED  41  go  to  IM  for  coordination 

40 

ADVANCE 

0 

Intrar.sit  time  to  IH 

41 

QUEjE 

ITLM 

Collect  waiting  time  stats  for  ITEMMGR 

42 

SEIZE 

itemmgr 

601 's  received  by  appropriate  IM 

43 

DEPART 

ITEM 

Calculate  waiting  time  stats  for  ITLM.MGR 

44 

ADV.ANCE 

RVEX?~f6.34) 

Item  manager  processing  time  for  631's 

45 

TEST  E 

FN(CASC) ,1,SKI?  5%  coordinated  with  CASC 

46 

QUEUE 

CREEK 

Collect  waiting  time  stats  for  CASC 

47 

SEIZE 

BATTLE 

CASC  begins  processing 

48 

DEPART 

CREEK 

Calculate  waiting  time  stats  for  CASC 
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49 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
61 
62 

63 

64 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 


ADVANCE  RVEXPO(10,34)  CASC  processing  time 

RELEASE  BATTLE  CASC  completes  processing 

SKIP  RELEASE  ITEMMGR  IK  returns  601  to  KR-ALC 

ADVANCE  0  Transit  time  from  IM  to  WR-ALC 

SEIZE  ROBINS  KR-ALC  receives  601 

ADVANCE  3  WR-ALC  performs  final  processing 

RELEASE  ROBINS  WR-ALC  notifies  base  of  approved  601 

OKED  ADVANCE  0 

TEST  E  &J,2,ST0P  Do  not  record  times  for  initialization 

BPUTPIC  PILE=EDIOK,LIHES=l,6I,N(OKED),Ml 

**  ttt  tt* 

TERMINATE  0 
OOT  ADVANCE  0 

TEST  E  &J,2,STOP  Do  not  record  times  for  initialization 

BPUTPIC  FILE=EDIBAD,LINES=l,iI,N(OaT),Hl 

tt  tt*  t** 

STOP  TERMINATE  0 

*  Run-Control  Xact 

tt*t***t*******t*t*tt***t**t*t*t************ittt**t»t*tt***t***1tttt*it**ttt**tt1ctt 

GENERATE  730  Simulate  730  days  (2  years)  system  operation 

TERMINATE  1  Terminate  run  at  end  of  2  years 

******t*t**i**ti**t*i*****i*i*t1ttt*ti*tt*1t**t**tittitt*tt*t****titt**tt*tttitttti 

*  Run-Control  Statements 

t***tt**t**t*tt*ti*it*i****Ut*ttti***t*tt***titit*tttti*tt*t*ttttttt*tH*t**t*t* 


DO  &I=1,10,1  Perform  10  replications 

LET  4J=1  Assip  value  of  4J 

RMULT  , 199000+1000*61 RN2  offset  for  current  replication 

299000+1000*61, _  RN3  offset  for  current  replication 

399000+1000*61, _  RN4  offset  for  current  replication 

499000+1000*61, _  RN5  offset  for  current  replication 

599000+1000*61, _  RH6  offset  for  current  replication 

699000+1000*61, _  RN7  offset  for  current  replication 

799000+1000*61, _  RN8  offset  for  current  replication 

899000+1000*61, _  RN9  offset  for  current  replication 

999000+1000*61,  RNIO  offset  for  current  replication 
START  1,NP  2-year  initialization  period 

RESET  Reset  all  statistics  to  zero 

LET  6J:2  Change  value  of  6J 

START  1  Run  model  for  effect 

CLEAR  Clear  all  stats  and  XACTs  from  the  model 

ENDDO  Next  value  of  61 


END 
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Appendix  E:  Residence  Times  for  System  With  EDI 


XACT  f  REP  11  REP  12 


1 

42 

.  7  2  7  8 

11.85436 

2 

47  . 

84005 

217.8282 

3 

3  9  . 

3  3842 

9  .787  93 

4 

22 

.8164 

5 . 09682 

5 

3  3  . 

00  58  3 

5.21699 

6 

51  . 

33335 

5.87453 

7 

49  . 

07894 

36.10444 

8 

49  . 

85943 

11.43354 

9 

S3  . 

87146 

26.23198 

10 

55  . 

56799 

27.27815 

11 

30  . 

8  4295 

56.04026 

12 

50  . 

04643 

61 .29762 

13 

66  . 

0  302  5 

57.64142 

14 

81  . 

22055 

79.13458 

1  5 

62  . 

0  40  48 

47.27895 

16 

52  . 

22305 

39.48284 

17 

6  5  . 

48  57  1 

45 .09724 

18 

62  . 

53  956 

44.98876 

19 

2  9  . 

80  27  4 

3  5  .  7  6682 

20 

34  . 

07  672 

27.62703 

21 

66  . 

82  67  5 

41.16817 

22 

70  . 

77209 

32.22887 

2  3 

68  . 

01554 

31.2227 

24 

65  . 

59581 

22.25025 

2  5 

67 

.026 

46.0832 

26 

49  . 

78456 

42  .  99889 

27 

69  . 

40281 

25.62486 

28 

59  . 

93754 

18.22066 

29 

46  . 

48272 

4.44073 

30 

33  . 

37986 

8.65941 

31 

30 

.300  5 

5  .  427  69 

32 

66  . 

20164 

24  .  54093 

3  3 

60  . 

57  169 

19  .59505 

34 

67  . 

7  2  539 

16. 98271 

3  5 

69  . 

18  561 

12.15322 

36 

69  . 

70134 

4  .  42169 

37 

7  7 

.9874 

26.14327 

38 

81  . 

1  90  93 

20.87431 

3  9 

113 

.664  9 

34.98624 

40 

96  . 

0  655  9 

26. 26126 

4  1 

112 

.0  661 

2  7  .  8  9202 

42 

119 

.1545 

30.17141 

4  3 

100 

.4  7  2  1 

12.74399 

4  4 

104 

.6132 

4.92023 

4  5 

10  1 

.0084 

15.13147 

4  6 

110 

.4153 

22.54789 

47 

126 

.12  61 

15.62365 

48 

164 

.0514 

26.84723 

4  9 

174 

.0  42  9 

30.25698 

50 

17  1 

.1084 

26. 14346 

5  1 

153 

.9109 

52 

153 

.7  344 

5  3 

54 

5  5 

56 

57 

58 

59 

60 

61 

62 

63 

64 

65 

66 

67 

REP  13  REP  14  REP  tS 
181.2966  223.6124  103.9782 
194 . 8314  229.753  46.3394 

158.7268  247.1133  40.49846 
165.6863  237.1745  45.40114 
164.5875  227.991  44.5664 

168.434  191.9103  31.33435 
150.0653  202.5821  31.85215 
149.8066  200.644  15.10377 

159.2515  180.2545  30.43022 
188.1374  283.221  28.83688 

192.5133  186.0296  24.45954 
195.5238  198.4319  19.63428 
196.5886  208.93  25.76229 

201.051  185.7512  66.88675 
222.657  192.8402  64.96243 
201.6441  207.8063  66.05727 
182.9911  196.3557  31.30822 
187.9934  206.8115  42.2227 

188.3621  246.5719  35.13179 
198.9616  210.9772  45.85458 
195.2667  226.2791  27.40349 
216.3875  215.6177  20.88828 
225.1117  207.3959  13.39031 
219.3263  200.3642  31.08375 
225.7422  167.9682  12.44669 
227.4669  168.4422  24.75486 
225.6077  165.443  52.26921 

223.507  169.0547  49.68857 
222.7387  177.0821  42.89822 
217.505  174.9335  46.27781 
215.3691  174.9649  29.99825 
209.8294  174.3075  42.2245 

196.4558  161.8412  52.03659 
175.404  125.7424  72.75688 
227.1061  127.4382  76.56377 
229.3349  131.5102  54.49347 
227.7938  141.188  54.41659 

226.0796  148.6765  59.99099 
239.4886  157.9607  55.30181 

251.7107  160.5246  56.1822 

241.0734  273.5017  55.09744 

197.6523  162.0486  40.51691 
179.8907  160.6173  43.82931 
189.9544  153.8464  34.6279 

149.3101  166.7477  46.7807 

98.05981  160.6633  45.65864 
315.4641  168.0749  48.4037 

83.98438  166.8629  67.32918 
104.7658  110.5096  79.23246 
136.5037  139.7944  64.78769 
98.91993  138.9596  36.59103 
106.3768  142.5381  29.27048 
67.56343  167.2745  15.00627 
166.4144  10.31495 
146.6977  15.44348 

166. 9669  60 .40332 
177.7742  55.85325 
182.7733 
173.7856 
159.  8122 
171.4959 
169. 9997 
176.1682 
190.0168 
184.7491 
186.935 
185.0889 
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XACT  t 

RBP  f  6 

RBP  #7 

RBP  18 

RBP  1  9 

RBP  tlO 

I 

10  . 

31852 

37.84066 

126.8007 

123 

.8475 

41.7393 

2 

6. 

52784 

28  .  9384 

129. 6811 

122 

.  2  624 

46.63668 

3 

8  . 

44497 

66.24899 

128.8713 

133 

.1072 

20.35921 

4 

1  5  . 

67  442 

53.9552 

131.9865 

124 

.  5395 

49.4661 

S 

21  . 

58  393 

47.3342 

97.56415 

121 

.  5082 

33.4711 

6 

20 

.8057 

36,61884 

104.4926 

123 

.7  968 

41.77757 

7 

45  . 

49606 

38.66945 

109.7039 

137 

.3254 

57.06416 

8 

95 

.5033 

94.82586 

108.6564 

152 

.5193 

51.43037 

9 

92  . 

34  396 

107  .  6794 

112.2041 

137 

.  2  32  1 

50.81709 

10 

96  . 

16786 

129.2264 

121.8049 

137 

.1147 

71.42684 

11 

139.958 

141  .0  631 

126.0762 

141 

.  5049 

80  .  5552  3 

12 

156 

.6178 

146.6555 

97.62245 

141 

.  6986 

69. 58485 

13 

162 

.  9326 

158.1775 

98 .20595 

244 

.1167 

84.92345 

1  4 

157 

.1379 

156.1628 

96.17086 

150.322 

80.53965 

IS 

162 

.7681 

87.96666 

69.57634 

144.817 

72.82928 

IS 

135 

.740  9 

72.92975 

60.46204 

152 

.0922 

14 . 20791 

17 

138.47 

57.08402 

43.67068 

148 . 56 

30.88009 

18 

164 

.9321 

59.1157 

42.46908 

135 

.  3422 

15.93126 

1  9 

184 

.2088 

55.63475 

41.93582 

142 

.  6968 

15.01346 

20 

18  1 

.1904 

155. 8797 

65.15877 

139 

.0418 

35.22555 

21 

163 

.7  991 

63.61174 

52.413 

148 

.  9942 

32.2386 

22 

149 

.0126 

30  .  61934 

52 . 18565 

150 

.  7823 

29.26082 

2  3 

133 

.1638 

S3 .04  60  6 

23 .29492 

149 

.  9081 

31.51083 

2  4 

114 

.  6798 

47  .  29585 

26.18981 

161 

.  8023 

46  .  60726 

2  S 

106 

.40  28 

51.90448 

22 .23117 

159 

.  582  6 

38.11976 

26 

91  . 

55043 

40.34082 

6.44629 

160 

.  6413 

61.21326 

27 

97 

.5  538 

38.54698 

23.26349 

158 

.  93  56 

21 .25299 

28 

109 

.8813 

31.71127 

30 .08697 

161 

.  7679 

6. 35916 

2  9 

93  . 

0  58  18 

19.14757 

34.12409 

172 

.  6891 

16.60536 

30 

91 

.97  49 

35.85327 

35 . 57551 

144 

.4713 

5,49746 

31 

101 

.0  139 

31  .7  357  3 

20.24582 

120 

.  1001 

23.06038 

32 

65 

.27  69 

40.9335 

5.53099 

83  . 

53126 

28.86358 

3  3 

77  . 

95  44  1 

1  5 .964  68 

18.4837 

70  . 

93952 

40  .  63874 

34 

69  . 

37328 

39.79262 

14.10946 

74 

.  6214 

48.59453 

35 

59  . 

70912 

63  .96114 

13.62942 

58  . 

25199 

30.58611 

36 

60  . 

81654 

63.78361 

31 . 46104 

54  . 

69115 

5.11386 

37 

5  6  . 

64191 

56.16543 

20.94944 

68  . 

0  3328 

22.8916 

38 

58  . 

67494 

57.33066 

24.85808 

54  . 

92693 

13.7982 

39 

54  . 

7  6928 

60.61861 

27  .04479 

38  . 

98641 

26.73554 

40 

50 

.9931 

66.  19864 

12.57216 

49  . 

41227 

41 

44  . 

8487  3 

55.77011 

25  .41315 

44  . 

2  52  1  5 

42 

50  . 

03415 

59. 64118 

45.25393 

39  . 

64  631 

4  3 

69  . 

51433 

78.0384 

54.42495 

38  . 

88472 

44 

7  4  . 

53004 

55. 67426 

64.10153 

43  . 

76777 

4  S 

71  . 

3  8  2  1  7 

68.93377 

57.65161 

50  . 

65476 

46 

89 

.9503 

63.61222 

41.74872 

15 

.6932 

47 

8  5  . 

3702  9 

64.75095 

39.2736 

16  . 

470  93 

48 

8  6  . 

552  7  3 

71.7615 

32.84553 

35 

.2742 

4  9 

8  9  . 

7  4  3  3  7 

70.61278 

40  .  24367 

50  . 

04114 

so 

8  9  . 

34081 

32  .08182 

45.91155 

52  . 

70919 

51 

8  6  . 

5957  6 

74 ,75143 

56  . 

80  607 

52 

8  1  . 

92427 

74 . 69634 

57  . 

29614 

5  3 

7  4  . 

77  198 

76.72619 

82  . 

41454 

54 

70  . 

8  94  66 

75. 85272 

72  . 

63787 

55 

52  . 

9507  9 

77.433 

97  . 

955  14 

56 

1  4  . 

99959 

70.34599 

76. 

69074 

57 

6  . 

4  62  5  3 

63.42736 

74  . 

47732 

58 

7  . 

3  6  991 

60 . 96284 

73  . 

15781 

5  9 

2  5  . 

2  30  32 

60.51018 

71 

.9466 

60 

30 

.0602 

32.32673 

25  . 

7  421  3 

61 

20  . 

94905 

62 

13  . 

682  48 

63 

10  . 

74889 

64 

43  . 

00255 

65 

50  . 

5887  4 

6  6 

48  . 

18  953 

67 

33  . 

63722 

68 

20 

.83  56 

69 

14  . 

1  62  49 

E-2 


Appendix  F:  601  Residence  Times  for 


XACT 


RBP  II 


RSP  12  RIP  13  RIP  14 


1. 

2 

3 

4 

3 

6 

7 

8 
9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

3  3 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

4  4 
45 

4  6 

47 

48 

49 

50 

51 

52 

5  3 

54 

55 

56 

57 

58 

59 

60 
61 
62 

63 

64 

65 


50.7278 
55.84005 
47 . 33842 
30.8164 
41.00583 
59.33335 
57.07894 
57.85943 
61.87146 
63.56799 
38.84295 
58.04643 
74 .03025 
89. 22055 
70 .04048 
60.22305 
73 . 48571 
70.53956 
37 .80274 
42.07672 
74.82675 
78 . 77209 
76.01554 
73.59581 
75.026 
57 . 78456 
77.40281 
67.93754 
54.48272 
41.37986 
38 . 3005 
74 . 20164 
68.57169 
75.72539 
77.18561 
77.70134 
85.9874 
89. 19093 
121 . 6649 
104.0656 
120 .0661 
127.1545 
108.4721 
112 . 6132 
109.0084 
118.4153 
134.1261 
172.0514 
182 .0429 
179.1084 
161  .  9109 


19.85436 
229.7719 
20.77087 
13.09682 
13.21699 
13.87453 
44.10444 
19.43354 
34.23198 
35.27815 
64 .04026 
69. 29762 
65.64142 
87.13458 
55.27895 
47.48284 
53.09724 
52.98876 
43 .76682 
35.62703 
49.16817 
40 .22887 
39.2227 
30.25025 
54.0832 
50.99889 
33.62486 
26.22066 
12.44073 
16. 65941 
13.42769 
32 . 54093 
27.59505 
24.98271 
20.15322 
12.42169 
34.14327 
28.87431 
42  .98624 
34.26126 
35 . 89202 
38.17141 
20.74399 
12 . 92023 
23.13147 
30 . 54789 
23.62365 
34.84723 
38.25698 
34. 14346 


171.2131 
189. 2966 
202.8314 
166.7268 
173.6863 
172 . 5875 
176.434 
158.0653 
157 .8066 
167.2515 
196.1374 
200.5238 
218 .8318 
204.5886 
209.051 
230 . 657 
190.9911 
217.6441 
195.9934 
196.3621 
206 . 9616 
203.2667 
224 . 3875 
233.1117 
227.3263 
233.7422 
235.4669 
233 . 6077 
231 . 507 
230.7387 
225.505 
223 . 3691 
217 .8294 
204.4558 
183.404 
235.1061 
237.3349 
235.7938 
234.0796 
247.4886 
259.7107 
249.0734 
205.6523 
187.8907 
197.9544 
157 . 3101 
106.0598 
326.8989 
91  .98438 
112 .7658 
106 .4723 
113.9292 
171 . 9032 


231.6124 
237.753 
255 . 1133 
245.1745 
235.991 
199.9103 
210 . 5821 
208.644 
188.2545 
295.9841 
195.0785 
206. 4319 
216.93 
193.7512 
200 .8402 
215.8063 
204. 3557 
214.8115 
215.9772 
269.8311 
234.2791 
223.6177 
215.3959 
208 . 3642 
175 . 9682 
176.4422 
173.443 
177 .0547 
185.0821 
182.9335 
182.9649 
182.3075 
169.8412 
133.7424 
135.4382 
139.5102 
149.188 
156. 6765 
165.9607 
168.5246 
167.0486 
282.4203 
168 .6173 
161.8464 
174.7477 
168.6633 
176.0749 
174.8629 
118  .  5096 
147.7944 
146.9596 
150.5381 
175.2745 
174.4144 
154.6977 
174.9669 
185.7742 
190.7733 
181.7856 
167.8122 
179.4959 
177.9997 
184 . 1682 
198.0168 
192 .7491 


Current  System 


RIP  15 

111.9782 
54.3394 
48.49846 
53.40114 
52.5664 
39. 33435 
39.85215 
23.10377 
38.43022 
36.83688 
32.45954 
27.63428 
33 .76229 
74.88675 
72 . 96243 
74.05727 
39.30822 
50.2227 
43.13179 
53.85458 
35.40349 
28.88828 
21 . 39031 
39.08375 
20.44669 
32 . 75486 
60.26921 
57.68857 
50.89822 
54.27781 
37  .  99825 
50.2245 
60.03659 
80 .75688 
84.56377 
62  .  49347 
62  .41659 
67.99099 
63.30181 
64.1822 
63.09744 
48.51691 
51.82931 
42. 6279 
54.7807 
53.65864 
56. <037 
75.32318 
87.23246 
72.78769 
4  4  .  5  910  3 
37.27048 
23.00627 
18.31495 
23.44348 
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REF  «7  REP  18 

45.84066  110.0134 
36. 9384  142 . 8007 
58.9552  137.6811 
104.2715  136.8713 
55.3342  139.9865 
44.61884  105.5642 
4  6  .  66945  112  .  4926 
102.8259  117.7039 
115.6794  116. 6564 
137.2264  120.2041 
149.0631  129.8049 
154.6555  103.8144 
166.1775  104.3979 
164.1628  102.3628 
95.96666  75.76831 
80.92975  158.3344 
65.08402  69.65401 
67.1157  52.86265 
63.63475  51.66105 
69.17726  51.12778 
36.18486  73  .  15877 
171.8797  60.413 

61.04606  60.18565 
55 . 29585  31 .29492 
59.90448  34.18981 
48.34082  30.23117 
46.54698  14.44629 
39.71127  31.26349 
27.14757  38.08697 
43.85327  42.12409 
39.73573  43.57551 
48.9335  28.24582 
23.96468  13.53099 
47.79262  26.4837 

71.96114  22 . 10946 
71.78361  21.62942 
64.16543  39.46104 
65.33066  28.94944 
68.61861  32.85808 
74.19864  35.04479 
63.77011  20.57216 
67.64118  53.25393 
86.0384  62.42495 
63.67426  82.47342 
76.93377  75.10153 
71.61222  68.65161 
72.75095  52.74872 
79.7615  50.2736 

78.61278  51.72337 
40.08182  48.24367 
53.91155 
82.75143 
8  2  .  69634 
84  .  72619 
83.85272 
85.433 
78  .  34599 
71.42736 
68 . 96284 
68.51018 
40  .32673 
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111.7676  58.07058 
131.8475  43.4795 

130.2624  49.7393 

141.1072  54.63668 
132.5395  28.  3  5921 
129.5082  57.4661 

131.7968  41.4711 

145.3254  49.77757 
160 .5193  65.06416 
145.2321  59.43037 
145.1147  58.81709 
149.5049  87.42684 
149.6986  88.55523 
155.322  77.58485 
263.4647  92.92345 
152.817  88.53965 
160.0922  80.82928 
156.56  22.20791 

143.3422  38.88009 
150.6968  23.93126 
147 .0418  2  3  .01346 
156.9942  43.22555 
158.7823  40.2386 

157.9081  37.26082 
169.8023  39.51083 
167.5826  54.60726 
168.6413  46.11976 
166.9356  69.21326 
169.7679  29.25299 
180.6891  14.35916 
152.4713  24.60536 
128.1001  13.49746 
91.53126  31.06038 
76.93952  36.86356 
82.6214  48.63874 
66.25199  56.59453 
62.69115  38.58611 
59.92693  13.11386 
76.11752  30.8916 

46. 98641  21.7982 

57.41227 
52 .25215 
47.64631 
46.88472 
51.76777 
58.65476 
23.6932 
24 . 47093 
43.2742 
58.04114 
60 .70919 
64.80607 
65.29614 
90.41454 
80.63787 
105.9551 
84.69074 
82.47732 
81.15781 
79. 9466 
33.74213 
28. 94905 
21.68248 
18.74889 
51  .00  2  55 
61.01781 
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